Library mismatch (wxWidgets?)

Archives Forums/Linux Discussion/Library mismatch (wxWidgets?)

plash(Posted 2008) [#1]
When I try to run code that uses the wxMax library it crashes with this:
/usr/bin/ld: warning: libstdc++.so.6, needed by /usr/lib/libwx_gtk2u_aui-2.8.so, may conflict with libstdc++.so.5
Fatal Error: Mismatch between the program and library build versions detected.
The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6),
and your program used 2.8 (no debug,Unicode,compiler with C++ ABI 102,wx containers,compatible with 2.6).
Aborted


I had to install some older version of wxWidgets to get code::blocks to work, could that be the problem?

I still have 2.8, 2.6, and 2.4 development packages installed..


Brucey(Posted 2008) [#2]
Possibly one compiled with gcc3 and one compiled with gcc4 ?

I'm guessing perhaps BlitzMax with gcc3 and the libs are gcc4... given the warning above.


dawlane(Posted 2008) [#3]
I have seen this before when I was using Brucey's wxMax module though I haven't seen this with code::blocks (yet. As most of my equipment is in storage while I'm decorating).
This seams to relate to what version of GCC wxWidgets was built with (a wild stab in the dark would point to GCC 4.2) and what the calling application was built with. If your like me and have BMax using GCC 3.3 that would be the problem.
What I suggest is making a temporary g++-3.3/gcc-3.3 link to call GCC 4.2 and let me know what happens.


Brucey(Posted 2008) [#4]
What I suggest is making a temporary g++-3.3/gcc-3.3 link to call GCC 4.2 and let me know what happens.

Funny, that used to work for me, but not on recent versions of Linux... I need to try a version of bmk which doesn't specify a "version" of gcc and see how that goes instead. Apps built with the symlink crash almost immediately for me - which is very strange. Like I said, it used to work.


dawlane(Posted 2008) [#5]
The g++-3.3/gcc-3.3 link tends to be a bit of a hit and miss affair. Some times it works and some times it doesn't.
I have tried modifying bmk but that cause more issues. I think the problem could be bcc


plash(Posted 2008) [#6]
I've had quite horrible experiences with symlinking.. as Brucey may recall :P

I'm fairly certain this only started happening when I installed code::blocks, although it's been awhile since I tried compiling a wx program.


Brucey(Posted 2008) [#7]
I think the problem could be bcc

bcc only generates assembler (.s) and has nothing to do with the final compiled binary.

bmk is the one which does the work of making sure everything gets compiled and linked with the correct programs.
I'm going to try a new BlitzMax install on Linux and see if a fixed bmk solves my issues... fingers crossed.
I would much rather have a working gcc4 build.


Brucey(Posted 2008) [#8]
gcc4 is a bit picky (with regards c++ standard), isn't it? I suppose it's better to be too picky than not enough though.


plash(Posted 2008) [#9]
The error message says something about 'wx containers,' is it referring to some specific wx class?


Brucey(Posted 2008) [#10]
no, that's a general statement which gives you an idea of what was compiled into the library.
The important bit as the ABI number... which indicates a different version of gcc.


dawlane(Posted 2008) [#11]
Here's something of interest http://www.trilithium.com/johan/2005/06/static-libstdc/


plash(Posted 2008) [#12]
How does that help us? Isn't the problem simply in wxWidgets?

I always get that libstdc warning, is it because BlitzMax insists on using libstdc++.so.5?


Brucey(Posted 2008) [#13]
it's because gcc3.3 links to libstdc++.so.5 and gcc4 links to libstdc++.so.6

Mixing standard library versions isn't really recommended, but generally it shouldn't be an issue.

wxWidgets initialization code probably checks the version the code expects and the version loading via the shared objects at runtime. Which isn't unreasonable.


I tried a rebuild of everything using gcc4 yesterday... and it looks like the GC blows up for some reason - on any BlitzMax apps I run. Which is a shame. The segfault is usually caught on a "New .....", and I've narrowed it down to possibly some of the membit checking/freeing stuff... dunno what's going on in there really tho ;-)
Bit strange all the same... maybe some of the optimisation of gcc has broken something in there...
oh well.


plash(Posted 2008) [#14]
But wait.. doesn't BlitzMax use the static libraries (compiled with gcc 3.3 - from the Google Code downloads for wxmax) when it tries to compile a program?

I'm almost completely lost to what exactly the problem is, I haven't fiddled with gcc/g++ or anything on the wx.mod side. Last thing I remember doing that was related to wxWidgets was getting Code::Blocks to install and run - and I don't really remember what I had to do, other then install an old version of wxWidgets.


Brucey(Posted 2008) [#15]
It's possible that it's picking up the system shared objects ahead of the static libs.
I guess there must be something one can add to the link options to make sure it looks in the local folders first.


plash(Posted 2008) [#16]
Just a note for any future problems, I rebuilt (and removed a ton of the older ones) the wx library Code::Blocks relies on and it (finally) works.

;)