Re: Linker ... still useful ?

Gregory Bond (gnb@bby.com.au) wrote:
: Linking is already enough of a bottleneck that there apparently is a
: market for third-party high-speed incremental linkers (e.g. Purelink).
: Any serious work on "ld-The Next Generation" is going to have to have
: parallelisation as a high priority. And given the global nature of the
: job, I'm not sure there is huge scope.


Mark Stavar (marks@orb.mincom.oz.au) wrote:
: I continue to be surprised each time we strike a linker that requires us
: to specify a library name more than once on the command-line in order to
: ensure resolution of symbol references.


Searching libraries repeatedly can be expensive - on our apollo machines
there are two linkers. The AEGIS environment linker 'bind' and the unix
environement 'ld'. The first of these will re-search libraries to ensure
resolution of symbol references the second does not. We had a large
application (over 10meg exe) built from about 50 libraries. When listed in
virtually the right order bind would take about 45 minutes to link on the
workstations we were using then. Using ld we had to repeat about two
libraries and use about 4 '-u' switches - the link took under 10 minutes.
My suspision was that 'bind' took so long because it was working through
all the libraries several times. I don't know if it remembered the symbol
tables from each of the libraries it had read it or if it had to reread
them each time arround.
--
Stephen Baynes baynes@mulsoc2.serigate.philips.nl
Philips Semicondutors Ltd
Southampton
United Kingdom
[This sounds to me like a design bug. It's hard to believe that there are
so many symbols in a realistic link that a linker couldn't keep enough info
in core to be able to resolve stuff without re-reading libraries. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.