Errors building C::B rev2688

[mandrav]

Same here, using GCC 4.1.1 on XP.

The error message, at least, seems fairly straightforward. CompileOptionsBase::GetLinkerOptions returns type wxArrayString, for which there is no function to directly push it on the stack. I don't pretend to understand the SqPlus sources very well, but it seems that the ReturnSpecialization class handles calling the various types of functions, and if there is no specialization for wxArrayString than the compiler would choose the function in SqPlusConst.h that is throwing the error.

I can't see how GCC 3.4.5 would compile it, but 4.1.1 not; so I'm probably missing something important.

Thanks for looking into it, TDragon. I 'm practically blind here since I don't have gcc 4.1.1 (but it works with gcc 4.0.3) so I appreciate any help I can get

Note: Below, I 'm talking about files located inside src/sdk/scripting

If you look in sc_base_types.h (which by the way is included by all other files in that dir), you will see that all bound types (including wxArrayString) are registered using the DECLARE_INSTANCE_TYPE macro.

This macro resolves to DECLARE_INSTANCE_TYPE_NAME_ which is defined in ../sqplus/sqplus.h at line 561 (and in ../sqplus/SqPlusConst.h at line 26).

These macros contain all the specializations for the registered type so it can be passed as argument or used as a return value.

So, obviously, wxArrayString's specializations are indeed defined. You can take it from here and check why it breaks. I (and many others) will happily wait for your investigation results

[mdelfede]

If you look in sc_base_types.h (which by the way is included by all other files in that dir), you will see that all bound types (including wxArrayString) are registered using the DECLARE_INSTANCE_TYPE macro.

This macro resolves to DECLARE_INSTANCE_TYPE_NAME_ which is defined in ../sqplus/sqplus.h at line 561 (and in ../sqplus/SqPlusConst.h at line 26).

These macros contain all the specializations for the registered type so it can be passed as argument or used as a return value.

So, obviously, wxArrayString's specializations are indeed defined. You can take it from here and check why it breaks. I (and many others) will happily wait for your investigation results

The error states that 'Push(SQVM*&, const wxArrayString&)' is missing; that's seems true to me, the function defined by DECLARE_INSTANCE_TYPE is 'Push(SQVM*, const wxArrayString&)', without extra indirection '&'.

Best Regards

Max

[mdelfede]

Did somebody find a solution ?
I was trying all day with no success....

Regards

Max

[killerbot]

no solution, been out of country for 2 days, just confirming I have this also, from the first revision with squirrel and still in today's revision. Suse Linux 10.1 (64bit) GCC 4.1.0
Just did a quick reading of the responses can we add both definitions for the pointer based and reference based (or even pointer reference based)

I hope this is fixed soon, otherwise I can't debug :-(  (since GDB on winXP64-bit crashes  and now I can't build on linux ...)

[Game_Ender]

I saw it mentioned here on the Ogre forums that there are problems with Sqplus and GCC 4.1.x, but is there even a stable release of 4.1.x or is it still in testing?  I don't think this is something Code::Blocks specific.

EDIT:  We probably want to jump in on the discussion over at the squirrel forums.

[mdelfede]

no solution, been out of country for 2 days, just confirming I have this also, from the first revision with squirrel and still in today's revision. Suse Linux 10.1 (64bit) GCC 4.1.0
Just did a quick reading of the responses can we add both definitions for the pointer based and reference based (or even pointer reference based)

I hope this is fixed soon, otherwise I can't debug :-(  (since GDB on winXP64-bit crashes  and now I can't build on linux ...)

Updated to GCC 4.1.2 prerelease SuSe, no changes.... I guess it's a problem of 4.1 series. It seems that when templates are instantiated the definition of Push(SQVM *, wxArrayString *) is not yet known, even it should.....

Inserting this
                ......................
                var(&ProjectFile::weight, "weight").
                var(&ProjectFile::compilerVar, "compilerVar");

SQVM *sss ;                                   <==
wxArrayString *xxx ;                       <==
SqPlus::Push(sss, xxx) ;                 <==

        SqPlus::SQClassDef<CompileOptionsBase>("CompileOptionsBase").
                func(&CompileOptionsBase::SetLinkerOptions, "SetLinkerOptions").
                func(&CompileOptionsBase::SetLinkLibs, "SetLinkLibs").
                ......................

gives no error in inserted lines, so the problem is not a definition missing of Push(SQVM*, wxArrayString *); I think is a template problem in 4.1 compiler. No solution yet   :cry:

<edit>
I found a similar problem in squirrel forum.... I'll ask there if somebody solved it.

[TDragon]

It seems that when templates are instantiated the definition of Push(SQVM *, wxArrayString *) is not yet known, even it should.....

Indeed. This has the appearance of either a GCC regression or some funky stuff in wxArrayString that GCC doesn't like.

A Temporary Fix:
Add the following to scriptbindings.cpp above the inclusion of "scriptbindings.h":

Code

class SQVM;
namespace SqPlus { void Push(SQVM*, const wxArrayString&); }

What I've Found So Far:
For some reason, the version of Push that is declared with the DECLARE_INSTANCE_TYPE macro trickery is not being found by the compiler. This is only happening for the wxArrayString version; others such as wxString appear not to have any issues. If its declaration or definition appears before the definition of struct ReturnSpecialization in sqplus.h (inside of which SqPlusConst.h and the Call function are included), the compiler is happy; if anywhere after (as far as I've seen), it complains.

I've been digging around in the preprocessed scriptbindings.cpp and found no reason it shouldn't work (as it apparently does in GCC 4.0 series and earlier), as the function is certainly defined before the template is actually instantiated with the call to func(). Further reports as results warrant.

[tekel]

from reading the GCC 4.1 release notes they did some fixes to the way GCC handles inlines
if you add these two CFLAGS the program compiles just fine

-frepo -fno-implement-inlines

However I am now getting linking errors, Might be the new flags might be somethign else.
I am implementing your fix now and will report back.

So I still have linking errors which tell me that the GCC options do in fact work :-D

[tekel]

After Passing the inline error I can compile C::B Properly but now I get this In linking

.libs/libcodeblocks.so.0.0.1
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object.
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: scripting/bindings/.libs/libsqbindings.a(scriptbindings.o): relocation R_X86_64_PC32 against `SqPlus::SQClassDef<ConfigManager>::SQClassDef(char const*, char const*)' can not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value


Any Suggestions

[killerbot]

class SQVM;
namespace SqPlus { void Push(SQVM*, const wxArrayString&); }

allowed me to build :-)

But it get this error message when CB starts up :

Code

SquirrelFunction<> call failed
AN ERROR HAS OCCURED [arith op + on between 'userdata' and 'userdata']

CALLSTACK
*FUNCTION [RegisterWizard()] /usr/local/share/codeblocks/templates/wizard/config.script line [51]
*FUNCTION [RegisterWizards()] /usr/local/share/codeblocks/templates/wizard/config.script line [11]

LOCALS
[category] USERPOINTER
[title] USERPOINTER
[folder] USERPOINTER
[type] 0
[this] TABLE
[this] TABLE

clicking on OK; leads the to the next error message :

GetInstance: Invalid argument type

clickin on OK --> finally in CB :-)

[mdelfede]

............
clicking on OK; leads the to the next error message :

GetInstance: Invalid argument type

clickin on OK --> finally in CB :-)

The same here with GCC 4.1.2 SuSe.......... still some problems, but at least now it works 

<edit>
it works, but about all relating to scriptings is broken... don't know if it's only my build's fault or because of SqPlus bug.

Regards

Max

[mdelfede]

The only thing that really helped was to install gcc 4.0.3 as an alternate compiler and rebuild all codeblocks sources.
Whith the warkaround more than half of the features were broken.

Here a page with a good howto for the installation of more GCC versions :

http://www.mjmwired.net/resources/mjm-fedora-gcc.html

I suggest to have gcc sources configured to give a suffix to executable names (e.g. gcc403 for the 4.0.3 version), in order to avoid mistakes on use. This is done with "--program-suffix=403" option, as explained in text.
I suggest also the installation in /opt/gcc/<version>, this allow for quick uninstall when needed. This is done with the --prefix=/opt/gcc/<version> option in configure.

After installing the new GCC, codeblocks can be built using it with these steps

export CC=/opt/gcc/4.0.3/gcc403
export CXX=/opt/gcc/4.0.3/g++403
./configure --enable-contrib
make

(all those for the 4.0.3 version I installed)

Best Regards

Max

[tr1gun]

Hi,
is there a fix for the problem that solves it without any errors?

cu

[zlbruce]

In C::B rev2745, I must add this two red lines to src/plugins/compilergcc/Makefile for building

INCLUDES = $(WX_CXXFLAGS) \
                -I$(top_srcdir)/src/sdk \
                -I$(top_srcdir)/src/sdk/wxscintilla/include \
                -I$(top_srcdir)/src/plugins/compilergcc/depslib/src \
                -I$(top_srcdir)/src/sdk/scripting/include \
                -I$(top_srcdir)/src/sdk/scripting/sqplus

My system is Debian Sid, and use dpkg-buildpackage to build a deb

[mandrav]

Hi,
is there a fix for the problem that solves it without any errors?

cu

I 'm currently installing SuSE 10.1 to see the problem myself (and attempt to fix it).
I won't tell you much, just that I remembered why I ditched rpm-based distros long ago