Mark Eschbach

Software Developer && System Analyst

Removing GNU Link’s link ordering.

I've yet to encounter a reason while writing a native application running under an operating system to care what order I'm linking the application modules. So recently I began the search to reduce the time spent concerning object file linking order.

My first thought was to search for a multi-pass option I could use with ld. Unfortunately after consulting the standard resources, I couldn't find one. Since ld and related binutil projects are generally rather large, adding a multipass options to the linker source was unrealistic in my project's time frame.

So time to get creative. From the linker's perspective, the order of symbols within any particular object file is not important. I know from previous experience ld will allow assembling a number of smaller modules into a larger module to allow for incremental linking. I began thinking you could define multi-pass linking as a series of incremental links.

So my creative work around, okay its a hack, is to link all of the object files into one large object file, then link the object file against the dependent libraries. This makes the order in which you link the objects irrelevant. Which means you don't spend time chasing down "symbol not defined" errors from ld because of module ordering. Anyways, here is my Makefile solution:

LDFLAGS=-L/usr/local/lib -lsome_library -lwhich_works

application: application.o
     $(LD) $(LDFLAGS) $? -o $@
application.o: module-a.o module-b.o module-c.o
     $(LD) $(LD_INC_FLAGS) $? -o $@
module-a.o: module-a.cpp
module-b.o: module-b.cpp
module-c.o: module-c.cpp