GNU ld, ELF and C++

[hjl@nynexst.com (H.J. Lu)]

> 
> 
> >BTW, Ian, how compatible is the GNU ELF ld with SVR4/x86 ld? Can it
> >be a dropin replacement? Has anyone tried to use the GNU ELF ld to
> >build a shared ELF library under SVR4/x86?
> 
> 	Yes, I used to do this all the time at my old job.  I intended it

Have you tried

gcc -shared -o libfoo.so *.o

with the GNU ld under SVR4/x86? First, GNU ld doesn't take the flags
for SVR4/x86 ld. Do you use a special specs for GNU ld under SVR4/x86?

I had to edit specs a little bit. I changed "%{shared:-G -dy}" to
"%{shared:-shared}".

My test case is little bit tricky since I am working on the ELF support
for the C++ shared library. My stuff works with the GNU as and SVR4/x86
ld, but not the GNU ld. If I create the shared C++ ELF library under
SVR4/x86 with the GNU as and SVR4 ld, the global ctors and dtors in
the shared C++ ELF library are called in the right order. But the
shared C++ ELF library created with the GNU as and GNU ld won't
call those global ctors and dtors at all. It looks that there are
bugs with creating the shared ELF library in the GNU ld. If anyone
is interested, I can send my test case.

> to be a drop in replacement, but the handling of the SHT_DYNSYM sections
> in our version of SVr4 was a bit weird, and Solaris treated things more
> logically.  That being said, a little work might be needed on some flavors of
> SVr4 to support a unified symbol table which the Dell SVr4 seemed to want.
> This could be a linker option, I think.
> 
> 

Eric, there is a bug in the Linux d-linker. It has something to
do with mixing the shared/static libraries. I will send you a
test case later this week.

-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com