Re: Bad crt files

Re: Bad crt files

[H.J. Lu]

> 
> Better.  But change the Makefile to use add -g to each compile and
> link step, then it segfaults again.

Can I use -g at the link step with the shared library since libg.a is
not a shared library? Can a shared library be loaded in without
libc.so? Maybe there is a bug the GNU ld that couldn't handle mixing
a shared library with a static C library right. Or is that a dynamic
linker bug?

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?

> 
> This simple example built fine with or without -g with the previous
> tool releases.
> 


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

Re: Bad crt files

[Eric Youngdale]

>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
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

GNU ld, ELF and C++

[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