From mboxrd@z Thu Jan 1 00:00:00 1970 From: hjl@nynexst.com (H.J. Lu) To: eric@aib.com (Eric Youngdale) Cc: raeburn@cygnus.com (Ken Raeburn), ian@cygnus.com (Ian Lance Taylor), gas2@cygnus.com Subject: GNU ld, ELF and C++ Date: Wed, 12 Oct 1994 22:18:00 -0000 Message-id: <9410130518.AA16303@titanic.nynexst.com> References: X-SW-Source: 1994/msg00131.html > > > >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