General linking question

Stefan Bellon sbellon at sbellon.de
Wed Aug 28 04:10:26 PDT 2002


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. 

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

> 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'.

Solution? You have to provide a stub strusage() in A' in order to link
against B.

Well.

-- 
 Stefan Bellon * <mailto:sbellon at sbellon.de> * <http://www.sbellon.de/>
 PGP 2 and OpenPGP keys available from my home page

 The day Microsoft makes something that doesn't suck
 is probably the day they start making vacuum cleaners.



More information about the gcc mailing list