This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Using a shared library to partly replace an archive library - ldchanged behaviour
- From: Graham Hudspith <gwh at allinea dot com>
- To: binutils at sourceware dot org
- Date: Tue, 26 Apr 2005 15:27:13 +0100
- Subject: Using a shared library to partly replace an archive library - ldchanged behaviour
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.
Why are we using a shared library? We want to provide ONE library which
can be used by many customers, each with their own version of the
archive library. We really DON'T want to have to provide many versions
of the shared library, each linked against a different version of the
archive library. Usually, the customer has provided their own build of
the archive library, customised for their site and providing our own
build is not really feasible.
We want to program against the interface supported by the archive
library, rather than the implementation.
I've read all the documentation to GNU ld several times. Some of the
options available look interesting, but nothing strikes out as being a
way to solve this problem.
Is what we are trying to do achievable?
Desirable?
Can GNU ld today be made to mimic the behaviour of a previous version?
Or was that previous behaviour a bug which has since been fixed?
Any answers, or pointers to answers, gratefully received!
Graham.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature