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.
Exactly.
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.
Yep. And linking a library when none of the symbols match your executable isn't terribly useful. ;)
Until the ABI is stable (which is should be now),
Shouldn't it have been *years* ago???
Perhaps it should. Shouldn't compilers have supported the entire C++ language years ago? Probably. It's a terribly complicated language, however.
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.
I actually meant *minor* version.... I apologise.
-- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
