static linking of libgcc on linux ?
kelly.ohair at oracle.com
Mon Oct 18 17:16:53 UTC 2010
On Oct 18, 2010, at 1:29 AM, Andrew Haley wrote:
> On 10/18/2010 12:51 AM, David Holmes wrote:
>> Just to revive this ...
>> Andrew Haley said the following on 09/27/10 20:06:
>>> In practice, it's often the other way round: static linking with
>>> libgcc on GNU/Linux causes more problems than it solves. If we're
>>> linking statically with libgcc now, it would be risky to start doing
>>> so again.
>> So the current situation is that if you build with gcc 3.x you will
>> static linking and with 4.x you won't. This seems to me to be an
>> oversight when we moved to gcc 4 builds.
>> That said, the lack of static linking does not appear to have harmed
>> So do we just leave this as-is or try to rectify it?
> Please leave it as it is.
> We gcc maintainers moved from statically linking libgcc to making it a
> dynamic library because of a library versioning problem. If, in a
> single process, two shared objects (or one shared object and a main
> program) are linked against different versions of libgcc all manner of
> things may break.
I have to agree with Andrew.
Static linking is never a great idea, but I understand is was done a
long time ago to
deal with some quality issues and maximize portability of the binaries
over many Linux systems.
I don't think those reasons are valid anymore.
I'm not sure this change was done by design or accident, but I'd vote
that we start
avoiding static links if at all possible. Just my opinion.
More information about the build-dev