Re: Issue building libgcc_s.so

[Ian Lance Taylor <iant at google dot com>]

John Marino <gnugcc@marino.st> writes:

> Although I had not run into a problem myself, I was informed that
> despite gcc being configured with --enable-shared that the port does
> not build libgcc_s.so and this will cause an issue propagating
> exceptions when shared libraries are used.

Note that if you are using a linker which supports the --eh-frame-hdr
option, and if your libc provides the dl_iterate_phdr function, and if
the gcc configure script figures those things out, then exceptions will
correctly propagate across shared libraries even if you don't use
libgcc_s.so.  That approach is also more efficient and should be used if
possible, so libgcc_s.so may not be an issue for you.


> I thought the solution was simple.  In the config.gcc file, I changed
> this line:
>        tmake_file="t-libc-ok t-libgcc-pic"
> to:
>        tmake_file="t-slibgcc-elf-ver t-libc-ok t-libgcc-pic"
>
> (Both dragonfly platforms are ELF)
>
> The result is that libgcc_s.so and libgcc_s.so.1 is built during the
> libgcc building phase.  There are lots of *_s.o and *_s.dep files
> being built as well.  so far, so good.
>
> The script then moves to the libada directory to build adalib.  It
> stops because the "can this compiler produce executables?" test fails.
>
> Looking at the config.log, the error is:
> /usr/libexec/ld-elf.so.2: Shared object "libgcc_s.so.1" not found,
> required by "a.out".
>
> To confirm, I took the command line instruction for xgcc and built a
> hello_world program with xgcc and got the exact same error.
>
> I don't know why this error is coming up.  My first suspicion is that
> the linker is trying to use the system libgcc_s library.  On
> Dragonfly, this file does not exist (yes, really).  Can anybody
> explain why I'm getting this error and how to fix it?

This could indeed be the problem.  Did you use --disable-bootstrap when
you ran configure?  When bootstrapping, this is supposed work due to the
setting of LD_LIBRARY_PATH in the top level Makefile before building
adalib.  Specifically, these lines:

	$(RPATH_ENVVAR)=`echo "$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \

TARGET_LIB_PATH = $(TARGET_LIB_PATH_libstdc++-v3)$(TARGET_LIB_PATH_libmudflap)$(TARGET_LIB_PATH_libssp)$(TARGET_LIB_PATH_libgomp)$(HOST_LIB_PATH_gcc)

Ideally libgcc_s.so.1 should be found via HOST_LIB_PATH_gcc.

(If you used --disable-bootstrap, then you are more or less responsible
for dealing with this yourself.)


> As a second related topic, this work, along with work on FreeBSD,
> NetBSD, and OpenBSD, is going into their software ports/packages
> trees.  libgcc_s.so builds in a common directory, e.g. /usr/local/lib/
> .  That means if somebody builds my Ada port, and then builds another
> gcc port in the tree, the second port's libgcc_s will overwrite the
> first.  I assume this is well-known issue.  What's the best way to
> handle it?

You'll have to ask the ports people.  In Debian or RPM packaging,
libgcc_s.so.1 is only installed by the core gcc package.

Ian