ld, shared objects and makefiles

John Fisher john.fisher@nec.com.au
Wed Aug 5 09:01:00 GMT 2009


When cross-linking a shared object, the linker command line refers to 
another shared object. I'm revising the GNU makefile that is responsible 
for instructing the linker. The makefile currently uses -L to specify 
the directory containing the referenced shared object, then -l to 
specify part of the file name.

 From the point of view of the makefile this is inconvenient. I'd rather 
specify the referenced shared object in the list of pre-requisites, then 
pass the same specification through to the linker. Instead of specifying 
the referenced shared object using -L and -l, I would specify the file 
name directly on the command line. The referenced shared object may have 
been updated: both outer and referenced share objects are home grown. 
The referenced shared object is just a part of a list of input files to 
the linker, all of which are also makefile pre-requisites. It seems 
obvious to use the same list for both makefile pre-requisites and input 
files to the linker.

This makefile methodology works just fine for .o object files and .a 
archives.

There's a problem when I do it this way with .so shared objects. The 
name of the directory containing the referenced shared object becomes 
part of the outer shared object. When dlopen is called for the 
referenced shared object, it can't be found. The paths to the referenced 
shared object on the development host and the target are different.

Is there any way short of going back to using -L and -l that I can tell 
the linker to ignore the name of the directory containing the referenced 
shared object on the development host?

Surely this problem has occurred before: how has it been solved?



More information about the Binutils mailing list