[TUHS] What does `ld` stand for?

[Dan Cross via TUHS]

On Sun, Oct 25, 2026, 2:12 PM christopher fujino via TUHS <tuhs at tuhs.org>
wrote:

> Ahh, thank you Bakul for that reference. With the Levine context and the
> source from v2, it seems to me like it means Link eDitor. Coincidentally, a
> friend had recommended that book for me to read, and I haven't gotten
> around to it yet. I really should!
>

I highly recommend John's book. It's one of the few resources of its kind,
and the only dedicated _book_ on linking and loading that I'm aware of, and
it's very well done.

        - Dan C.


On Sun, Oct 25, 2026 at 11:08 AM Bakul Shah <bakul at iitbombay.org> wrote:
>
> > On Oct 25, 2026, at 10:42 AM, christopher fujino via TUHS <tuhs at tuhs.org
> >
> > wrote:
> > >
> > > My friend, taking an OS course was wondering what `ld` stood for. After
> > > doing an online search, concluded "no one knows." Surely someone around
> > > here must remember why the linker is called `ld`? Thanks!
> >
> > From John R. Levine's "Linkers & Loaders" book:
> >
> > As early as 1947, programmers started to use primitive
> > loaders that could take program routines stored on separate
> > tapes and combine and relocate them into one program. By the
> > early 1960s, these loaders had evolved into full-fledged
> > linkage editors.
> > ...
> > Programmers were using libraries of subprograms even before
> > they used assemblers. By 1947, John Mauchly,who led the
> > ENIAC project, wrote about loading programs along with
> > subprograms selected from a catalog of programs stored on
> > tapes, and of the need to relocate the subprograms’ code to
> > reflect the addresses at which they were loaded. Perhaps
> > surprisingly, these two basic linker functions, relocation and
> > library search, appear to predate even assemblers, as Mauchly
> > expected both the program and subprograms to be written in
> > machine language. The relocating loader allowed the authors
> > and users of the subprograms to write each subprogram as
> > though it would start at location zero, and to defer the
> > actual address binding until the subprograms were linked with
> > a particular main program.
>