Jonathan Bartlett wrote:
RH9 uses an updated libstdc++ which can cause problems. Also, if you areSo you're basically saying that I have to compile *all* my C++ code for Red Hat 9 (i.e. gcc 3)?
exporting anything but "c"-style functions declared with extern c or
whatever that is, you will NOT have compatibility at all. There is some
work for a standard C++ ABI, but it's still a little fluid.
Yes. DSO's from 7.3 would be linked against libstdc++-libc6.2-2.so.3. DSO's from 9 would be linked against libstdc++.so.5. If you tried to link a C++ binary against both, it would end up linked against both libstdc++ versions, and no good could come of that.
Is there really no way around this?
You can either compile all of your libraries and applications on RHL9, or install the appropriate compat-* packages, including the older compiler, and compile using the older compiler set to link against the older libstdc++. Until the ABI is stable (which is should be now), there won't be compatiblity between libraries built by different versions of the compiler.
I notice that the *runtime* linker is quite happy to accept binaries from Red Hat 7.3 (gcc 2)
As long as the libraries to be linked are coherent (as in, only on libstdc++ to load), you should expect older binaries to load properly.
I'm not sure what happens if you mix binaries from the two versions (e.g. by replacing one of the DSOs without relinking the app.)
The last time I saw that done was when I was using RHL 5.2. I installed KDE from an older release and a version of QT for 5.2 (or something like that). The mixture of libraries simply caused the loader to go into a loop and eat CPU time.
-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
