Library mismatch (wxWidgets?)

When I try to run code that uses the wxMax library it crashes with this:


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..

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.

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.

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.

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

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.

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.

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.

The error message says something about 'wx containers,' is it referring to some specific wx class?

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.

Here's something of interest http://www.trilithium.com/johan/2005/06/static-libstdc/

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?

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.

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.

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.

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.

;)