Top-level libgcc question (IA64/Linux bootstrap failure)

Roger Sayle roger@eyesopen.com
Sat Feb 3 22:09:00 GMT 2007


I'm trying to track down the cause of a bootstrap failure that I'm seeing
on ia64-unknown-linux-gnu, that I think may have been caused either by the
move of libgcc to the top-level or some recent libunwind changes.

The issue is that I'm on an older Linux distribution that doesn't provide
a system libunwind, so libgcc builds a suitable libunwind.{a,so} itself.
Unfortunately, the failure I'm seeing is during the build of
libgcc_s.so.1.tmp that the linker fails with "cannot find -lunwind".

In theory, the problem should be reproduceable with the configure option
--without-system-libunwind, but the failure mode is such that the linker
will just silently continue to pick up the system /lib/libunwind.*.

I suspect the fix is that I just need to figure out where to stick a -L./
or specify ./libunwind.so or something during the libgcc.so link step.


However, during my investigations I have discovered a related change in
behaviour with Dan's patch to move libgcc to the top-level.  Previously,
the file gcc/mklibgcc contained the lines:

>>  # Shared libraries.
>>  if [ "$libgcc_s_so" ]; then
>>    echo ""
>>    echo "$libgcc_s_so: stmp-dirs $libunwind_so"

which when necessary would create a dependency for libgcc_s.so on
libunwind.so.  However, in the current libgcc/Makefile.in, there appears
to be no-way to get libgcc_s$(SHLIB_EXT) dependent upon
libunwind$(SHLIB_EXT).  Indeed my current failure is when attempting to
build libgcc.so, which is done *before* building libunwind.so.

Any thoughts, advice or fixes would be appreciated.  This is a regression,
as I was last able to build mainline on this same system on 20061030.

Thanks in advance,

Roger
--




More information about the Gcc-patches mailing list