I have been building GCC 4.6 C and Ada front-ends cleanly for several
months. The Ada FE regression testsuite is run regularly and it comes
up error-free on both ACATS and gnat.dg.
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.
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?
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?
John
