Re: Distributing a .so built with GCC 4.7.0

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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



[Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

Add to Google