Compilation error with SuSE Linux 9.3 on AMD64

[MortenMacFly]

I'm trying to compile C::B from SVN on Linux but I get an unexpected error during compilation. I followed the steps from the WiKi (http://wiki.codeblocks.org/index.php?title=Compiling_Code::Blocks_in_Linux_%28applies_to_all_distros%29) which works so far until I do the make for C::B. Then I receive the following error:

Code: [Select]

g++ -DHAVE_CONFIG_H -I. -I. -I../../../src/sdk -I/usr/lib64/wx/include/gtk2-unicode-release-2.5 -I/usr/include/wx-2.5 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -I../../../src/sdk/wxscintilla/include -I../../../src/sdk/tinyxml -I../../../src/sdk -I../../../src/sdk/as/include -I/usr/lib64/wx/include/gtk2-unicode-release-2.5 -I/usr/include/wx-2.5 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -O2 -ffast-math -g -O2 -I/usr/lib64/wx/include/gtk2-unicode-release-2.5 -I/usr/include/wx-2.5 -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -MT sc_io.lo -MD -MP -MF .deps/sc_io.Tpo -c ./bindings/sc_io.cpp  -fPIC -DPIC -o .libs/sc_io.o
In file included from ../../../src/sdk/manager.h:14,
                 from bindings/sc_io.cpp:2:
../../../src/sdk/sdk_events.h: In member function `virtual wxClassInfo*
   CodeBlocksDockEvent::GetClassInfo() const':
../../../src/sdk/sdk_events.h:119: error: `cbAddDockWindowEvent' undeclared
   (first use this function)
../../../src/sdk/sdk_events.h:119: error: (Each undeclared identifier is
   reported only once for each function it appears in.)
../../../src/sdk/sdk_events.h:119: error: syntax error before `;' token
I searched the forum for this error without success. I'm pretty dumb on Linux, so I might be missing something simple. I'm using the wxGTK package that ships with this version of SuSE (wxGTK 2.5.3). This works with a simple wxWidgets sample application but might not be sufficient for C::B...?! Do I need to compile wxGTK 2.6.3 before? Any hints?
With regards, Morten.

[mandrav]

Yes, you need wxGTK-2.6.x to build C::B.

[MortenMacFly]

Yes, you need wxGTK-2.6.x to build C::B.

Yes, that did the trick. It was quite complicated because I'm not an admin on this machine so I needed to make sure the right wx-config is called and things (I cannot uninstall the wxGTK 2.5.3). But now it works! That's more-or-less my first compilation of a GUI application under Linux. Since this worked nearly flawless I have to say: Great work with the Setup/compile/install system!!!
With regards, Morten.

[MortenMacFly]

I have to apologise. I was about to change the WiKi section to add the hint about wxGTK 2.6.x and found the prerequisites section. It is written there that I need 2.6.1 or above. Sorry for that. :oops: :oops: :oops:
With regards, Morten.

[MortenMacFly]

It's not my day today. Compilation worked, but not linking - I've been too fast. May I ask again for this issue:

Code: [Select]

g++ -O2 -ffast-math -g -O2 -I/home/ftmh/projects/wxGTK-2.6.3/build_gtk2_shared_monolithic_unicode/lib/wx/include/gtk2-unicode-release-2.6 -I/home/ftmh/projects/wxGTK-2.6.3/include -I/home/ftmh/projects/wxGTK-2.6.3/contrib/include -DGTK_NO_CHECK_CASTS -D__WXGTK__ -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D_LARGEFILE_SOURCE=1 -o .libs/codeblocks app.o appglobals.o compilersettingsdlg.o crashhandler.o dlgabout.o dlgaboutplugin.o environmentsettingsdlg.o main.o prefix.o printdlg.o splashscreen.o startherepage.o -pthread -Wl,-rpath -Wl,/home/ftmh/projects/wxGTK-2.6.3/build_gtk2_shared_monolithic_unicode/lib -pthread -Wl,-rpath -Wl,/home/ftmh/projects/wxGTK-2.6.3/build_gtk2_shared_monolithic_unicode/lib  -L/home/ftmh/projects/codeblocks/src/src/wxAUI /home/ftmh/projects/codeblocks/src/src/wxAUI/.libs/libwxaui.a -L/home/ftmh/projects/wxGTK-2.6.3/build_gtk2_shared_monolithic_unicode/lib -L/usr/X11R6/lib64 -lm -lc -lgcc_s -L/home/ftmh/projects/codeblocks/src/sdk /home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so /home/ftmh/projects/codeblocks/src/sdk/wxscintilla/.libs/libwxscintilla.so /usr/lib64/libstdc++.so -lpthread -ldl -lwx_gtk2u-2.6 -Wl,--rpath -Wl,/home/ftmh/tmp/lib
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBoxBase::DoInsert(wxString const&, int)'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBox::DoGetItemClientObject(int) const'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `wxWindowBase::UnregisterHotKey(int)'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBox::DoSetItemClientData(int, void*)'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `wxWindowBase::RegisterHotKey(int, int, int)'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBox::DoSetItemClientObject(int, wxClientData*)'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBox::GetCount() const'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBox::SetString(int, wxString const&)'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBox::GetString(int) const'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `wxWindowBase::ApplyParentThemeBackground(wxColour const&)'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBoxBase::Select(int)'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBox::DoAppend(wxString const&)'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `wxListBoxBase::Select(int)'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBox::Clear()'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBox::GetSelection() const'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBox::FindString(wxString const&) const'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBox::DoGetItemClientData(int) const'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `non-virtual thunk [nv:-584] to wxListBox::Delete(int)'
/home/ftmh/projects/codeblocks/src/sdk/.libs/libcodeblocks.so: undefined reference to `wxListBox::SetSelection(int, bool)'
collect2: ld returned 1 exit status
Any hints and beating is welcome. :cry:
With regards, Morten.

[MortenMacFly]

May I ask again for this issue: [...]

Ok, one step for: I figured out that I had to set the LD_LIBRARY_PATH variable to include the non-default wxGTK LIB-folder in front but not removing any other entries. Furthermore I had to make sure the PATH variable is extended to include wx-config and stuff of the additional wxGTK compilation/installation bin folder. Thus this bin folder had to come before the bin folder of the other wxGTK as well.
Now compilation and linking works but when I start C::B I receive that an AS method could not be registered. I remember that AngelScript was not working under a 64 bit OS so I'm doing further investigations on this... Anyway: As I see one should really have only ONE wxGTK installation otherwise things get weired.... :roll:
With best regards, Morten.

[MortenMacFly]

Mmmmh... I guess I really could need some help. I tried different things as proposed in the forum to patch and/or disable AngelScript for the 64bit system I'm trying to compile C::B for but without success. Could someone who runs C::B on a 64bit system enlighten me what to do with AS? Or where can I read about it?
What happens? I can compile C::B but when I try to run it a small message box (without text) pops up and closes shortly after that. On the console the following error is written:

Code: [Select]

codeblocks: source/as_anyobject.cpp:138: void RegisterAnyObject(asCScriptEngine*): Assertion `r >= 0' failed.
I tried AS_MAX_PORTABILITY and the patch as proposed by Takeshi Miya but it doesn't help...?!
With regards, Morten.

[takeshi miya]

I tried AS_MAX_PORTABILITY and the patch as proposed by Takeshi Miya but it doesn't help...?!
With regards, Morten.

What you're talking about is here. It only removed the assertions and ignored AS.

But that was resolved as noted here, so I don't know why you're experiencing them. Works fine for me.

[MortenMacFly]

But that was resolved as noted here, so I don't know why you're experiencing them. Works fine for me.

I didn't find this one. So does that mean that the SVN version should just work fine? Well, I tried again: Removing everything in my home folder and made a complete re-build from scratch with revision 2397. But I got the same error. I don't have access to any "base folder" (like /usr, /lib or similar) since I'm a restricted user so it cannot be another conflicting libcodeblocks or similar. Anyway, I searched and "which'd" all binaries (C::B and libs) - wxGTK as well as C::B seems to be in place and are the right ones I'd like to use... Very strange...?! Any others that have C::B running on a 64bit machine, maybe even SuSE Linux (9.3)?
With regards, Morten.

[mandrav]

Morten,

I work on a 64bit system and Angelscript is disabled automatically since it doesn't support it yet.
Can you run the following command in a terminal and post its output?

Code: [Select]

touch foo.h && cpp -dM foo.h


[MortenMacFly]

Can you run the following command in a terminal and post its output?

Sure, here it is:

Code: [Select]

#define __athlon_sse__ 1
#define __DBL_MIN_EXP__ (-1021)
#define __FLT_MIN__ 1.17549435e-38F
#define __CHAR_BIT__ 8
#define __WCHAR_MAX__ 2147483647
#define __DBL_DENORM_MIN__ 4.9406564584124654e-324
#define __FLT_EVAL_METHOD__ 0
#define __unix__ 1
#define unix 1
#define __x86_64 1
#define __SIZE_TYPE__ long unsigned int
#define __ELF__ 1
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __FLT_RADIX__ 2
#define __LDBL_EPSILON__ 1.08420217248550443401e-19L
#define __SSE_MATH__ 1
#define __athlon 1
#define __SHRT_MAX__ 32767
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
#define __x86_64__ 1
#define __linux 1
#define __unix 1
#define __LDBL_MAX_EXP__ 16384
#define __LONG_MAX__ 9223372036854775807L
#define __linux__ 1
#define __SCHAR_MAX__ 127
#define __DBL_DIG__ 15
#define __USER_LABEL_PREFIX__
#define linux 1
#define __STDC_HOSTED__ 1
#define __SSE2__ 1
#define __LDBL_MANT_DIG__ 64
#define __FLT_EPSILON__ 1.19209290e-7F
#define __LDBL_MIN__ 3.36210314311209350626e-4932L
#define __WCHAR_TYPE__ int
#define __FLT_DIG__ 6
#define __FLT_MAX_10_EXP__ 38
#define __INT_MAX__ 2147483647
#define __amd64__ 1
#define __gnu_linux__ 1
#define __FLT_MAX_EXP__ 128
#define __DECIMAL_DIG__ 21
#define __DBL_MANT_DIG__ 53
#define __WINT_TYPE__ unsigned int
#define __SSE__ 1
#define __MMX__ 1
#define __LDBL_MIN_EXP__ (-16381)
#define __LDBL_MAX_10_EXP__ 4932
#define __DBL_EPSILON__ 2.2204460492503131e-16
#define _LP64 1
#define __DBL_MAX__ 1.7976931348623157e+308
#define __tune_k8__ 1
#define __DBL_MAX_EXP__ 1024
#define __SSE2_MATH__ 1
#define __amd64 1
#define __athlon__ 1
#define __FLT_DENORM_MIN__ 1.40129846e-45F
#define __LONG_LONG_MAX__ 9223372036854775807LL
#define __FLT_MAX__ 3.40282347e+38F
#define __GXX_ABI_VERSION 102
#define __FLT_MIN_10_EXP__ (-37)
#define __FLT_MIN_EXP__ (-125)
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 3.64519953188247460253e-4951L
#define __DBL_MIN__ 2.2250738585072014e-308
#define __PTRDIFF_TYPE__ long int
#define __LP64__ 1
#define __LDBL_MIN_10_EXP__ (-4931)
#define __REGISTER_PREFIX__
#define __LDBL_DIG__ 18
#define __NO_INLINE__ 1
#define __FLT_MANT_DIG__ 24
#define __VERSION__ "3.3.5 20050117 (prerelease) (SUSE Linux)"
Please note that it maybe not possible at all due to some configuration I don't know. I cannot update and/or add/remove packages on that machine. So if we don't find a solution I'll look for another linux machine here at work... ;-)
With regards, Morten.

[mandrav]

This is really strange.
Can you try the following?

Edit src/sdk/as/bindings/scriptbindings.cpp and insert at line 75, i.e. as the first line in RegisterBindings():

Code: [Select]

#ifdef _LP64
return;
#endif

This should avoid registering anything with scripts on 64bit machines. Hopefully this means you will not hit that assertion again...

[MortenMacFly]

Thanks for the help, I tried but unfortunatelly...

Hopefully this means you will not hit that assertion again...

...this is what still happens. :-(

Code: [Select]

codeblocks: source/as_anyobject.cpp:138: void RegisterAnyObject(asCScriptEngine*): Assertion `r >= 0' failed.
I don't understand this. If I got your change right this method should never be called. So why is the assertion raised? Anyway: I see the welcome screen which I didn't see before, but that can also be an issue with the work load on that linux (server). Generally the configuration of the linux system seems to work - any other wxWidgets applications I've compiled meanwhile using wxGTK 2.6.3 is working properly, too.
I maybe should contact the dev of AngelScript...?!
With regards, Morten.

[MortenMacFly]

2 Remarks:
1.) ...I saw that there is a new version (2.6.0) of AngelScript. Is it difficult to try to integrate this one with C::B? Did you (mandrav) just use the lib or did you already patch in in some way?
Edit: Why I'm saying this: Because the differences of 2.5.0b (which C::B is using) and 2.6.0 (which is the current one) are clearly 64bit related.
2.) You posted #ifdef _LP64. But the foo thing you posted earlier shows a _LP64__ define. Did you really mean just one leading underscore?
With regards, Morten.

[mandrav]

1.) ...I saw that there is a new version (2.6.0) of AngelScript. Is it difficult to try to integrate this one with C::B? Did you (mandrav) just use the lib or did you already patch in in some way?
Edit: Why I'm saying this: Because the differences of 2.5.0b (which C::B is using) and 2.6.0 (which is the current one) are clearly 64bit related.

Yes, I know. I 'm the one trying to port AS to 64bit
Andreas (author of AS) did some basic adjustments to the library but I 'm working on the hard stuff.
Besides, AS-2.6.0 adds classes support which is a major update (not just 64bit compat. fixes).

2.) You posted #ifdef _LP64. But the foo thing you posted earlier shows a _LP64__ define. Did you really mean just one leading underscore?
With regards, Morten.

What I see is:

Code: [Select]

#define _LP64 1
just below this:

Code: [Select]

#define __DBL_EPSILON__ 2.2204460492503131e-16