John Marino <gnugcc@xxxxxxxxx> 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
