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
not
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
get
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
anything.
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.
http://gcc.gnu.org/ml/gcc/2000-04/msg00610.html
Andrew.
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.
-kto
