|Linker ... still useful ? guerin@IRO.UMontreal.CA (1994-09-21)|
|Re: Linker ... still useful ? firstname.lastname@example.org (1994-09-22)|
|Re: Linker ... still useful ? email@example.com (1994-09-22)|
|Re: Linker ... still useful ? firstname.lastname@example.org (1994-09-23)|
|Re: Linker ... still useful ? email@example.com (Joel Runes) (1994-09-26)|
|Re: Linker ... still useful ? firstname.lastname@example.org (1994-09-26)|
|Re: Linker ... still useful ? email@example.com (Rob MacLachlan) (1994-09-27)|
|Re: Linker ... still useful ? firstname.lastname@example.org (1994-09-28)|
|Re: Linker ... still useful ? email@example.com (1994-09-28)|
|Linker ... still useful ? Roger@natron.demon.co.uk (1994-09-28)|
|Re: Linker ... still useful ? firstname.lastname@example.org (1994-09-29)|
|Re: Linker ... still useful ? email@example.com (1994-09-30)|
|Re: Linker ... still useful ? firstname.lastname@example.org (1994-10-05)|
|[4 later articles]|
|From:||Rob MacLachlan <email@example.com>|
|Organization:||School of Computer Science, Carnegie Mellon|
|Date:||Tue, 27 Sep 1994 17:19:18 GMT|
Joel Runes <firstname.lastname@example.org> wrote:
> I don't understand what would cause linkers to go out of date.
Although it is unlikely that separate compilation will go away any time soon,
current linkers are very lacking in their support for most modern languages.
1] Namespace -- Most linkers implement a more or less flat namespace, whereas
most modern languages don't. This can be handled to some degree by
prefixing, but that clearly isn't the best solution. In general linker
names become little more than random unique IDs, and some pre-linker phase
must make sure that the names really are unique.
2] Interface compatibility -- Ideally, many aspects of interface compatibility
checking would be put off until link time. In practice, few linkers have
any support for compatibility checking.
3] Initialization -- Most modern languages have a concept of more-or-less
anonymous chunks of initialization code which are run before the main
Less mainstream problems seen in dynamic languages like Lisp and SmallTalk:
4] Incremental linking -- The conventional linker doesn't support incremental
redefinition of functions in running applications, so implementors must
write their own linker anyway.
5] Heap preallocation -- In languages with GC, often all objects (including
static constants) are allocated in the heap. Conventional linkers don't
support pre-initializing the heap at link-time.
Because of these problems, the easiest and most efficient way to get interface
safety and incremental redefinition is often to write your own linker, even if
you have to write support for a.out file linking as well.
However, I have to admit I'm not sure what could come after current linkers.
Support for multiple namespaces and initialization is straightforward, but
interface checking is language dependent, and incremental linking and heap
preallocation are dependent on the particular implementation as well as on the
[A surprisingly effective way to do interface checking is to hang a byte string
on each procedure symbol that somehow encodes the arguments passed (for refs)
or expected (for defs) and for the linker to compare the strings and complain
if they're not the same. For interlanguage calls the compilers have to agree
on what the encoding is, but the linker needs only see if the bits are the
same. The Dartmouth PL/I linker used this trick back in about 1975. -John]
Return to the
Search the comp.compilers archives again.