Quote:Original post by George2

Quote:Original post by MaulingMonkey

Quote:Original post by Chozo
Actually, it turns out that the problem is the symantec scan engine library we link against. The fellow that got everything running on his linux machine neglected to mention that he didn't have those libs, and so had commented out all the code using them. When I gave that a try, everything worked just fine.

My question on this account would be, I'm using Gentoo with gcc 3.3.5 and the symantec lib says it was compiled with gcc 3.2.2 (well, it's in a folder called RedHat_gcc3_2_2 anyway). Would that cause a problem? I can't imagine that it would, but it doesn't look like there's an updated version of the lib on the symantec site. In face, their v4.3 scan engine uses the v4.1 sdk, which I find quite odd.

Well:

1) If there was a bug in 3.2.2 that was fixed in 3.3.5, that could cause a problem.
2) If the lib uses C++ code, binary compatability can I believe be broken on minor releases by normal numbering schemes (emphisis on believe). This assumes the classes sort of "overlap" the "DLL boundry" (to use windows speak). Aka, if you're using a class in your main binary who's functions are implemented in the lib, you could have problems.

I have a hard time believing that the gcc people would break binary compatability in minor releases. Major releases ok, but not minor.

I know binary compatibility isn't broken for minor with C code, and this is old and recycled information from my head on the C++ code, so you may be right (I remain cautious/skeptical however).

That said, it looks like binary compatibility is probably not the problem, for the following reasons:

1) They'd probably alter the name mangling to prevent errornus linking, and considering you've been getting it to run without such errors would make that seem unlikely.

2) "Starting with GCC 3.2, GCC binary conventions for C++ are based on a written, vendor-neutral C++ ABI that was designed to be specific to 64-bit Itanium but also includes generic specifications that apply to any platform."

This lends fire to the idea of breaking binary compatibility (I think) but such a recent change would indicate that they probably didn't change it in 3.3 right away considering 3.3 is noted in the documentation (although note this is a 3rd party site which may be out of date).

(for googleites in training, I searched for "C++ binary compatibility GNU" without quotes).

Edit: looks like my caution for minor releases remains valid, however. See http://gcc.gnu.org/ml/gcc/2002-07/msg00226.html, for example, on 3.1 -> 3.2 - the kind folks working on GCC definately WANT to keep binary compatibility accross a major version, but there's plenty of room for problems along the way.

YET ANOTHER EDIT: All that said, it sounds like there still may be issues with 3.2 <-> 3.3, such as with the standard library, which apparently is not directly covered by the strive for compile ABI compatibility, and which although the GNU folks are striving to keep compatible, was at least having major issues in the 3.1 <-> 3.2 switch.

I'd suggest at least trying a compile with 3.2 (remember to remake everything ^_^;;) and/or with 3.3 using 3.2's libstdc++. It's worth a try, at least.

[Edited by - MaulingMonkey on February 20, 2005 3:16:26 AM]