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
