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


On Tue, Apr 26, 2005 at 03:27:13PM +0100, Graham Hudspith wrote:
> We're struggling to overcome (understand, even) a difference in 
> behaviour between GNU ld v2.13.90.0.18 and v2.15.92.0.2, under Linux on 
> the x86 platform. I'm hoping someone here will be kind enough to explain 
> what's going on?
> 
> Apologies for being a complete newby in this area, I'm an ld user and 
> not an ld developer!
> 
> Our customers are used to linking their applications against an archive 
> library. This library contains two sets of functions. The first set of 
> functions usually ends up calling another in the second set of functions 
> (but not the other way around).
> 
> We want to, err, interpose a shared library between the application and 
> the archive library. The customer would link their application against 
> our shared library before the archive library on the command line. The 
> shared library contains a replacement set of the first set of functions. 
> This replacement set will do some work and then call one of the 
> functions from the second set of functions, still present in the archive 
> library.
> 
> On Redhat 9, with GNU ld v2.13.90.0.18, we can build and link our shared 
> library WITHOUT having to link the shared library against the archive 
> library. The user links their application against our shared library and 
> THEN the archive library. Running objdump on the resulting binary shows 
> lots of undefined symbols which are then satisfied when run with the 
> shared library. When the application invokes one of the "first set of 
> functions", these are caught and implemented by the shared library which 
> then goes on to call one of the "second set of functions" from the 
> archive library.
> 
> Great, just what we want.
> 
> Fast forward to Fedora Core 3 (or Gentoo, or Ubuntu) with GNU ld 
> v2.15.92.0.2, and everything breaks. This is after rebuilding from 
> scratch, of course. Running objdump on the resulting binary shows NO 
> undefined symbols. When the application invokes one of the "first set of 
> functions", these are caught and implemented by the ARCHIVE library 
> which then goes on to call one of the "second set of functions", also 
> from the archive library.  Our shared library is ignored. If we build 
> our shared library by linking it into the archive library first, 
> everything works fine, but this is not what we want.
> 

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? If you believe something is changed, please
open a bug report at

http://www.sourceware.org/bugzilla/

with a testcase and assign it to me. I will look into it.

Thanks.



H.J.

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


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