Re: Using a shared library to partly replace an archive library - ld changed behaviour

["H. J. Lu" <hjl at lucon dot org>]

On Wed, Apr 27, 2005 at 05:28:00PM +0100, Graham Hudspith wrote:
> H. J. Lu wrote:
> 
> >I am not sure if I understand what you are saying. It seems to work
> >
> >for me with the testcase enclosed here:
> >
> >[hjl@gnu shared]$ make
> >gcc -B./ -O -g   -c -o main.o main.c
> >gcc -B./ -O -g -fPIC -c foo.c -o shared.o
> >gcc -B./ -shared -o libshared.so shared.o
> >gcc -B./ -O -g   -c -o bar.o bar.c
> >ar rv libfoo.a bar.o
> >ar: creating libfoo.a
> >a - bar.o
> >gcc -B./ -O -g   -c -o foo.o foo.c
> >ar rv libfoo.a foo.o
> >a - foo.o
> >gcc -B./ -o main1 main.o libshared.so libfoo.a -Wl,-rpath,.
> >gcc -B./ -o main2 main.o libfoo.a
> >./main1
> >Shared library
> >./main2
> >Static library
> >rm foo.o bar.o
> >
> >Does it work for you? 
> >
> Thanks for the swift reply (and source code too!).
> 
> Rather annoyingly, your examples worked as expected ;-)
> 
> So I decided to investigate the compilation of the archive library 
> further. Using "gcc -H" and "gcc -E", I have reproduced and translated 
> the code they use inside your example bar.c (see attached).
> 
> It seems they are doing something wacky with weak symbols (thanks for 
> hinting about this, btw Dave Korn!).
> 
> They are also compiling their source code with -fPIC and then adding it 
> to the archive library !?
> 
> I have modified your Makefile and bar.c to mimic the behaviour of this 
> archive library. main1 and main2 are the same as before, except that 
> main1 no longer finds the correct foo(). I've also added a main3 that 
> DOES find foo(), but this is by linking in the archive to the shared 
> library beforehand. We DON'T want to do this.
> 
> What's going on? Are we at fault? Or the maintainers of the package that 
> produces the archive library? Or gcc? Or ld?
> 
> Is there some simple (or complicated) fix we can do to our shared 
> library that will make it work, unlinked, with the archive library?
> 
> Now, remember, there is a difference in behaviour between RH9 (gcc 
> v3.2.2, ld v2.13.90.0.18) and FC3 (gcc v3.4.3, ld v2.15.92.0.2).
> 

It is a combination of ld and ld.so. Weak symbols are treated as
strong when DSO is involved. If you want a DSO to override a symbol
in an archive, you have to make sure that the .o file which contains
the symbol can ONLY be used to resolve that symbol. In your case,
bar.o defines both foo and bar. Linker sees foo when it tries to
resolve bar.


H.J.