Issue building libgcc_s.so

[John Marino <gnugcc at marino dot st>]

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