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