Using a shared library to partly replace an archive library - ldchanged behaviour

[Graham Hudspith <gwh at allinea dot com>]

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