Thanks Ian, it looks as though a version script is exactly what I need :) On 27 April 2012 15:01, Ian Lance Taylor <iant@xxxxxxxxxx> wrote: > calzakk <calzakk@xxxxxxxxx> writes: > >> I've got GCC 4.7.0 built and am using this to build a component (.so). >> This will be built on certain platforms (Solaris and various Linux >> distros) then distributed to users, who will then integrate it into >> their application. >> >> I can't require that they then build GCC 4.7.0 - they'll likely be >> using an older version, even the stock 3.4.2 on Solaris 10. >> >> So what's the best course of action for me to take? Should I >> distribute libstdc++.so.6 and libgcc_s.so.1 (from my GCC 4.7.0 >> installation) along with my component that users can use instead of >> what's with their compiler? Is this nonstandard and/or dangerous? >> Should I statically link my component with these instead? (I haven't >> quite got this working, but I understand this will cause problems >> anyway?) > > In general everything should work correctly if the final program uses > the newer libstdc++.so.6 and libgcc_s.so.1. Note that it won't work if > the final program attempts to use both libstdc++.so.5 and > libstdc++.so.6. > > Natively statically linking your shared library with libstdc++ and > libgcc (which you can do using -static-libstdc++ -static-libgcc) will > not work reliably if your customer winds up using your library with GCC > 4.8.0 in the future. But you can make -static-libstdc++ -static-libgcc > work reliably by using a version script (this is how libstdc++.so > ensures backward compatibility, in the sense that a program compiled by > GCC 4.6.0 can run with a libstdc++.so built by GCC 4.7.0). You would > write your version script to only expose the symbols that are part of > your interface, and to hide all other symbols including all libsdtc++ > symbols. > > Or, you can distribute libstdc++.so.6 and libgcc_s.so.1, and explain to > the user that they should arrange to link dynamically against the newest > version of these libraries, either yours or (once they are using GCC > 4.8.0 or later) theirs. > > Ian
