This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

*** RH9 version ***
[opt-testing@fender modified]$ 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 libshared1.so shared.o
gcc -B./ -O -g -fPIC -c bar.c -o bar.o
ar rv libfoo.a bar.o
a - bar.o
gcc -B./ -o main1 main.o libshared1.so libfoo.a -Wl,-rpath,.
gcc -B./ -o main2 main.o libfoo.a
gcc -B./ -shared -o libshared3.so shared.o libfoo.a libfoo.a
gcc -B./ -o main3 main.o libshared3.so libfoo.a -Wl,-rpath,.
./main1
Shared library
Real Foo (or Bar)
./main2
Real Foo (or Bar)
./main3
Shared library
Real Foo (or Bar)

*** FC3 version ***
[gwh@snowball modified]$ 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 libshared1.so shared.o
gcc -B./ -O -g -fPIC -c bar.c -o bar.o
ar rv libfoo.a bar.o
ar: creating libfoo.a
a - bar.o
gcc -B./ -o main1 main.o libshared1.so libfoo.a -Wl,-rpath,.
gcc -B./ -o main2 main.o libfoo.a
gcc -B./ -shared -o libshared3.so shared.o libfoo.a libfoo.a
gcc -B./ -o main3 main.o libshared3.so libfoo.a -Wl,-rpath,.
./main1
Real Foo (or Bar)
./main2
Real Foo (or Bar)
./main3
Shared library
Real Foo (or Bar)

The RH9 version behaves as we want, the FC3 (or Gentoo, or Ubuntu) does not.

Hope this helps! And is interesting enough that you have got this far!

Graham.

Attachment: bug1.tar.gz
Description: GNU Zip compressed data

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]