This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
ld, shared objects and makefiles
- From: John Fisher <john dot fisher at nec dot com dot au>
- To: binutils at sourceware dot org
- Date: Wed, 05 Aug 2009 19:01:31 +1000
- Subject: ld, shared objects and makefiles
- Reply-to: john dot fisher at nec dot com dot au
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?