Re: Linker ... still useful ?

Joel Runes <z005465b@bcfreenet.seflin.lib.fl.us> 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.
Major problems:
  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
        entry.


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


    Rob
[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 comp.compilers page.
Search the comp.compilers archives again.