NetBSD system static libgcc is too old and causing problems

John Marino gnugcc@marino.st
Wed Jan 19 14:44:00 GMT 2011


Ian Lance Taylor wrote:
> It's decidedly odd that gcc is linking against the system libgcc.a at
> build time.  That should not happen.  gcc should always link against the
> appropriate libgcc.a.
> 

Agreed.  That's why it took me so long to recognize what was happening. 
  I wasn't looking for this possibility.  Is there another explanation 
that the software builds after eliminating /usr/lib/libgcc*.a ?


> It's completely normal that programs compiled by gcc are linking against
> the system libgcc_s.so at runtime.  gcc does not try to force the
> runtime time linking path, as there are many different possibilities
> that need to be handled, too many to really plan for.  In order to use
> different versions of native gcc on the same system, you need to install
> the newest libgcc_s.so where the dynamic linker looks, or you need to
> use -Wl,-rpath or LD_RUN_PATH to control where the programs look, or you
> need to use -static-libgcc to avoid dynamic linking of libgcc.
> 
> Ian

So in this case -static-libgcc doesn't help because both packages where 
I encounter this, the static libgcc was being used already (the wrong 
one).  The other methods will probably work, but they'll have to be 
applied every time gcc is used.  In other words, it wouldn't be an 
occasional override, but one to be applied always.  Ideally gcc should 
be configured to work as expected without special overrides.

John



More information about the Gcc-help mailing list