General linking question

Tony van der Hoff tony at mk-net.demon.co.uk
Wed Aug 28 03:43:25 PDT 2002


On 28 Aug 2002, in message <4b6d070d2asbellon at sbellon.de>,
Stefan Bellon <sbellon at sbellon.de> wrote:

> Peter Naulls wrote:
> > In message <4b6d00a4basbellon at sbellon.de>
> >           Stefan Bellon <sbellon at sbellon.de> wrote:
> 
> [snip]
> 
> > > How to link A and B together without the need of C? Is this possible
> > > under RISC OS?
> 
> > If my understanding of linker semantics is correct,
> 
> ... but on GNU/Linux, the gcc linker handles it (I have been told).
> 
> > then the way to do this is to split the functions up in B into
> > smaller objects.  i.e. A uses functions in B that are in the same
> > object file as functions which rely upon C.
> 
> Yes, that's how I do it at present. But in order to keep the RISC OS
> source as close as possible to the mainstream source it would be easier
> if it worked otherwise.
> 
> RISC OS linkers are able to exclude unused areas from the executable.
> But the dependence checks seem to be done prior to excluding unused
> areas. Why isn't this swapped around? Then the unused areas can have
> further dependences, but they needn't be fulfilled as the area is
> unused and therefore excluded anyway.
> 

I think you're mistaken, at least as regards Acorn's linker. I've no real
experience of the GCC linkers, so can't comment on these, but would assume
they would work in a similar way. I do realise this is the GCC list, so
please feel free to ignore my irrelevant words of wisdom :-)

Acorn's Link builds a table of unsatisfied symbol references as it processed
object modules. When all objects have been dealt with, each library is
searched in the order specified for symbol matching those on the list, and
where found, only the module defining that symbol is loaded, and the symbol
is removed from the table. If in the course of loading the library module new
unreferenced symbols are generated they are added to the table, and the
library is re-scanned (but any libraries already processed are not). Only if
there are still unsatisfied references left after the first library is
scanned will the next library be scanned, and the process repeated. In my
experience this works correctly.

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.

I suggest your problems are likely to be caused by a badly designed (or
implemented) library, where a module is dragging in unnecessary runtime code
(i.e. the granularity of the modules is inadequate) which itself is dragging
in stuff from C.

-- 
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 mailing list