Actually, I think the runtime linker will try to load all relevant versions , and make sure the correct one is used in each case
But when the compiler/linker is trying to resolve symbols, how does it know which symbol to use? The two, incompatible versions of the C++ library will provide conflicting symbols. It won't work out. You've seen that it does not.
I think it knows (because it can find out what version each and every object or DSO was linked with.) If however, different versions have different rules for how a symbol is named, everything gets a lot more confusing.
I see now why symbol resolution is not an issue even though an older compiler or OS has been used to build (as long as the same one is used for all object.) The runtime linker obviously only needs to concern itself with the symbols that are actually in the binaries; it doesn't need to know how they map into C++ objects or whatever, and it won't really notice that the symbol names are formatted differently from the way some other release of the compiler would.
[ ... ]
Surely the lib version issues may be resolved by passing the appropriate linker command line arguments?
No, that will not be sufficient.
It should be sufficient for the libstdc++ version issue, but not the symbol naming one.
Until the ABI is stable (which is should be now),
Shouldn't it have been *years* ago???
Perhaps, but it was not. I am not a GCC developer, so I don't know the situation well, but I believe that only recently has there been a C++ ABI that compiler vendors have agreed on.
That would be a good argument for updating in an incompatible manner. The lack of a standard is OTOH *not* a good reason for changing the binary interface between releases.
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
Mixing libs from various releases of Red Hat 6 and 7 generally works fine.
For C libraries, that is probably true. You can not, however, mix objects built by different major versions of the GCC C++ compiler.
Of course, GCC was on the same major version for *years* until relatively recent release of 3.0.
- Toralf
-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
