Herbert Saal wrote: > What can i do? With symbol versioning, compatibility works backwords but not forwards -- a binary built against an older libstdc++ should normally function correctly with a newer libstdc++ found on the machine at runtime. Thus the solution is to install the oldest version of gcc you wish to support on your development machine and link with it. This doesn't mean you necessarily need to use this old version of gcc to develop with, as you can have as many versions installed on the machine as you want. Just use the old version to produce the final binary. > One option i think is to static compile the libstdc++ library in my shared library. what is the instruction to do that? That's a very bad idea. Static linking works well for programs, but for a shared library it's going to be a nightmare because it means your lib will be loaded into a program that is likely dynamically linked against some other version of libstdc++. Thus you get essentially two copies of libstdc++ code, and if you try to pass objects between your code in your shared library and the code in the main program you have to ensure that all data structures are laid out exactly the same or compatible, otherwise you get random crashes or other unexplainable behavior. In other words, this solves nothing but just makes the problem ten times harder to debug. Not to mention the practical issue that the code in the static libstdc++ archive is not built PIC and so you can't link it into a shared library (the exception being i386, where it's allowed but with a performance penalty of relocs that make your text section non-sharable so what's the point.) Brian
