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
