General linking question
Tony van der Hoff
tony at mk-net.demon.co.uk
Wed Aug 28 05:32:13 PDT 2002
On 28 Aug 2002, in message <4b6d0e0545sbellon at sbellon.de>,
Stefan Bellon <sbellon at sbellon.de> wrote:
> Tony van der Hoff wrote:
> > Under your scenario, A will cause unresolved references to be
> > generated, which will be resolved by B, without loading any modules
> > which refer to C. Therefore, as I understand it, the linking process
> > will be complete after scanning B, and C will be ignored, as you
> > require.
> No, that's not the case! In B there's an unresolved symbol, but the
> function which depends on it isn't needed by A. Nevertheless, during
> linking it is shown as missing and link aborts.
Are you observing this behaviour with all linkers? In that case I must be
mistaken. It is not, however behaviour that I've previously seen, nor what
I have seen documented. Do you have a minimal test case that you can send me?
> > I suggest your problems are likely to be caused by a badly designed
> > (or implemented) library, where a module
> Could you please define your meaning of "module" in this context?
> Compilation unit?
Yes, effectively a compilation or assembly unit. more generally, any object
module that is included in the library (it is not necessarily compiled).
> > is dragging in unnecessary runtime code (i.e. the granularity of the
> > modules is inadequate) which itself is dragging in stuff from C.
> Ok, let's make a real-world example. There's a library (the above B)
> which contains lots of utility stuff needed. In this library there are
> functions that call a function strusage(). This needs to be provided by
> the program itself (the above C, but in this case equivalent to A).
> So, every program A that implements this function strusage() has no
> problem to link against B. But another program A' that doesn't
> implement the strusage() function cannot be linked against B, even if
> those functions inside B that call strusage() aren't used in A'.
Yes, that is what I understood from your original description. I would
suggest either (a) that something within B is calling strusage(), and that
function is being called by A, or (b) that strusage() is defined in a
module which declares another (required) symbol, and therefore is dragging in
strusage() as a side effect.
Run LibFile against the library to list the symbol table, see which object
module defines strusage and then see which other symbols that module defines.
Then check that your A' is not calling them.
> Solution? You have to provide a stub strusage() in A' in order to link
> against B.
That is certainly a work-round under these conditions. I would not call it a
solution. However, if this works with a minimal stub, it suggests that the
problem is likely to be (b) above.
Tony van der Hoff | MailTo:tony at mk-net.demon.co.uk
| MailTo:avanderhoff at iee.org
Buckinghamshire, England | http:www.mk-net.demon.co.uk
More information about the gcc