Linkers

Generally you can't get far without a linker. Linkers are important tools in the production of an Operating System. They come in many flavours, sizes, shapes, and formats. Some are flexible and some are not.

This page is about picking the right linker for dev'ing. If you're wondering HowLinkersWork, you're on the wrong page :P

There are important considerations to make when choosing a linker:

Does it support the output formats I require ?

Some linkers only support one kind of output file format, others support every kind of format known to exist. Formats are often not proprietary, having specifications available means if you wish to use Win32/PE file format, you are not required to use Microsoft's Linker.

Does it support the input formats I'm using?

This can be important if you're going to mix files around. For example, stock distribution works with COFF files, and if you link in a TASM assembled OBJ/OMF file, DJGPP(LD) will not recognise it.

This is usually of less a concern than the other requirements.

Can it specify address ranges for code and data?

This can be very, very important! Especially if you want to produce flat binary files (like an unrelocated kernel image). You need to be able to specify where the code starts and sometimes where the data begins.

Can it produce flat binary files?

As with the above option, this can be important, even if you only need to use it a couple of times.

Can it handle 32bit code?

You might think this is a redundant question in the age of "32bit" but there are many custom linkers out there that can't handle 32bit object files.

Is it free (price)?

It is a good idea for any Open Source OS developer to pick a freely available linker (and compiler) that you can offer as part of the "compilation tools package". Asking any potential contributor to find the latest VisualCodingStudio (apologies if it really exists) just to build your kernel will be a show stopper.

JLoc

JLoc was written by John Fines; the docs are still online (http://my.execpc.com/~geezer/johnfine/jloc.htm), but the download page (http://www.erols.com/johnfine/) seems to have vanished...

"This program is a linker/locator for use when you need more control over placement of sections within the image, than a standard linker provides."

JLoc can be tricky to use for first timers. Carefull reading of the documentation is required. Its not a get-up-and-go linker like all the other linkers. JLoc requires you to write a custome script for each "executable" image you want to link. JLoc gives you flexibility over HOW the object files are linked, regarding loaded addresses and so-forth.

• Pros

  • Supports OMF/OBJ, DJGPP/COFF
  • Supports 32bit code
  • Supports flat binary file generation
  • Handles library files (OMF/OBJ)
  • OMF/OBJ debugging information
  • Free

• Cons

  • Does not support any output file formats other than flat binary and DOS/COM
  • Confusing to use for beginners
  • Can't create shared libraries

ALink

ALink (Anthony's Linker) was written as a companion to NASM, its aim to provide a Free linker that supports Nasm's output formats and support some of the more popular executable formats. ALink is hosted at SourceForge, http://alink.sourceforge.net, but had its last file release in 2000...

• Pros

  • Its Free
  • Supports input formats OMF/OBJ, Win32/COFF Objects
  • Supports output as DOS/COM, DOS/EXE, Win32/PE
  • Can build Win32/PE DLL files
  • Can set the code address
  • Suppots .LIB (OBJ) Library files

• Cons

  • Doesn't support flat binary images
  • Strips debugging information
  • Can't create shared libraries

LD (GNU)

LD (available as part of the binutils package, at http://www.gnu.org/software/binutils/) is the King of linkers. Supports more input and output formats than any other linker in existance. Also the most flexable of the listed linkers. Supports custom linking via scripts. Its advanced featers are hard to use if you don't know what you are doing. LD has the most going for it in terms of functionality compared to the other linkers (Thats my opinion anyway...) but lacking OMF/OBJ support is a BIG omission.

This description is based on the LD sources, that can compile to support all formats. Please be aware that the LD that comes with DJGPP is very limited in its output formats (DJGPP/COFF, A.Out, flat binary), and also the LD that is part of Linux etc. - you have to ./configure and recompile LD to your requirements.

• Pros

  • Supports most known input formats (Elf, DJGPP/COFF, Win32/COFF, A.Out, etc)
  • Supports most known output formats (Elf, Win32/PE, A.Out, COFF, etc)
  • Supports creation of shared libraries
  • Can create flat binary files
  • Can specify code/data addresses
  • Supports DWARF and ECOFF and STABS debugging information
  • Its Free

• Cons

  • Does not support OMF/OBJ file format
  • Can get complex writing custom linking scripts

LD does not create shared libraries by itself. You have to give the proper flags to GCC itself so that it can generate position-independent code (note that this is talking about ELF shared libraries only).

LD is able to link while keeping relocations in your final object (called the 'incremental link'), and it also can stand unresolved symbols if instructed to do so.

On the PE side, you have to use a huge hack to get LD to generate relocatable DLLs. This involves running LD three (!) times:

ld -s --base-file $(BASE).base --dll -o $(TARGET) $(OBJS) $(LIBS) $(LDFLAGS)
dlltool --as=as --dllname $(TARGET) $(DTFLAGS) --base-file $(BASE).base --output-exp $(EXP_TEMP)
ld -s --base-file $(BASE).base --dll -o $(TARGET) $(OBJS) $(LIBS) $(LDFLAGS)
dlltool --as=as --dllname $(TARGET) $(DTFLAGS) --base-file $(BASE).base --output-exp $(EXP_TEMP)
ld --dll -o $(TARGET) $(EXP) $(OBJS) $(LIBS) $(LDFLAGS)

You might also want to check out ar in LinkArchiver, a libraries companion for LD.

TLink / TLink32 (Borland)

TLink is the linker that comes with Borland C and their assembler TASM. The difference between TLink and TLink32 is that TLink32 creates ONLY Win32/PE (and DLL) files where as TLink creates Dos and Win16 files.

• Pros

  • Supports Win32/COFF and OMF/OBJ
  • Has support for libraries
  • Supports creating Win32/PE files and DLL's
  • Supports OMF/OBJ (and DWARF?) debugging information

• Cons

  • Lacking in both input and output fileformats
  • Can't create flat binary images
  • Can't create shared libraries

Link / NLink (Microsoft)

There are really three fundamentally different linkers.

Versions 1.x through 3.x can only produce DOS output. Technically, the really early ones can only produce .com files, and IIRC, starting with 2.x they can also produce .exe files.

Starting with version 4.x, MS Link can also produce NE format output files. These accept OMF/OBJ format with some MS extensions.

Starting with version 6.x, MS link can produce only PE format output files.

These accept either COFF/PE or 32-bit OMF/OBJ format object files and produce (only) PE files as output. They support a few things missing from the Borland linker such as the ability to specify the entry point. Debug formats supported include COFF and CodeView.

Here I should note that I'm listing only the relatively mainstream versions of MS link. They've also produced versions that produce various other formats of output, mostly for OS/2 and/or Windows 3.x VxDs (e.g. LE and LX format).

VAL

VALink is an old old linker that has been floating around for ages. It is showing its age quite well. There exists an Enhnaced VALink that needs a review!

• Pros

  • Its free
  • Supports makeing DOS/EXE files.

• Cons

  • Can ONLY handle 16bit code.

WLink (Watcom Linker)

WLink is the linker that comes with Watcom C/C++. Supports a wide range of options and is flexible to a degree. The only problem is that Watcom just uses the virtual address entries of the ELF format, which can be specified at link time with the offset=0x???????? directive.

While this is a correct interpretation of the ELF specs, GRUB reads the physical address fields to determine where to put the code. To overcome this problem, use the tool elfix, which copies the virtual address fields to the physical address fields (works fine).

• Pros

  • Supports range of input formats, OMF/OBJ, Win32/COFF, ELF
  • Supports library files
  • Supports many output file formats from EXE, LE, Win32/PE, Novell NLM files, Pharlap files, QNX, OS2, etc.
  • Handles setting code offset address
  • Supports Watcom, Codeview and Dward debugging information

• Cons

  • Can't do flat binary files

  The link above doesn't appear to be relevant, any thoughts? --Kemp

Comparison