Re: Linker ... still useful ?

marks@orb.mincom.oz.au (Mark Stavar)
Wed, 5 Oct 1994 05:07:13 GMT

          From comp.compilers

Related articles
[6 earlier articles]
Re: Linker ... still useful ? ram+@cs.cmu.edu (Rob MacLachlan) (1994-09-27)
Re: Linker ... still useful ? steve@cegelecproj.co.uk (1994-09-28)
Re: Linker ... still useful ? jan@neuroinformatik.ruhr-uni-bochum.de (1994-09-28)
Linker ... still useful ? Roger@natron.demon.co.uk (1994-09-28)
Re: Linker ... still useful ? gnb@bby.com.au (1994-09-29)
Re: Linker ... still useful ? andrew@cee.hw.ac.uk (1994-09-30)
Re: Linker ... still useful ? marks@orb.mincom.oz.au (1994-10-05)
Re: Linker ... still useful ? ok@cs.rmit.oz.au (1994-10-06)
Re: Linker ... still useful ? monnier@di.epfl.ch (1994-10-07)
Re: Linker ... still useful ? baynes@ukpsshp1.serigate.philips.nl (1994-10-10)
Re: Linker ... still useful ? dmason@uwaterloo.ca (1994-10-15)
| List of all articles for this month |
Newsgroups: comp.compilers
From: marks@orb.mincom.oz.au (Mark Stavar)
Keywords: linker
Organization: Mincom Pty. Ltd.
References: 94-09-179
Date: Wed, 5 Oct 1994 05:07:13 GMT

Gregory Bond (gnb@bby.com.au) wrote:
: Sure, 70's technology linkers are old, but they have one major advantage:
: doing a simple job, they can be quick. The more work the linker has to
: do, the slower it gets. And linking is the the one part of the program
: building process that has a serial bottleneck. The more work that we can
: push into the "compiler", the better we are able to use multiprocessors
: (simply by using a parallel make, if nothing else).


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


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.


Another area is one of hard limits, for numbers of symbols, etc. This has
bitten us several times when combining objects that derive from C code, C
code generated by Oracle's Pro*C embedded SQL precompiler, and MicroFocus
Cobol (ugly isn't it !-P). By the time all of this reaches the link
phase, we are exceeding the 64K limit on numbers of global symbols allowed
in objects. Oracle is the major offender here, with something like 3
global symbols generated for every host variable (including indicator
variables).


<stepping onto highest available soap box ...>


In this day of high performance machines and cheap disk/memory, why impose
hard limits, even very large ones. This is certainly a throw-back to the
above mentioned 70's technology. Fixed table sizes, linear searches,
etc., are a thing of the past. For too long we have had to endure silly
limitation, hacking together work-arounds, fighting....


<stepping off soap box, somewhat embarrassed...>


Ahem. Sorry about that. Think you get the drift of what I think would be
nice enhancements.


Ciao,


marks
--


Post a followup to this message

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