This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: ld doesn't check for ld.so.1 in /lib
- From: Ian Lance Taylor <ian at airs dot com>
- To: Robert Millan <zeratul2 at wanadoo dot es>
- Cc: bug-binutils at gnu dot org, binutils at sources dot redhat dot com, glibc-bsd-hackers at nongnu dot org, glibc-bsd-devel at lists dot alioth dot debian dot org
- Date: 03 Aug 2003 18:39:07 -0700
- Subject: Re: ld doesn't check for ld.so.1 in /lib
- References: <20030730013508.GA24581@aragorn> <20030730025859.GA24781@aragorn><m3ptjsd7hu.fsf@gossamer.airs.com> <20030804032508.GA647@aragorn>
Robert Millan <zeratul2@wanadoo.es> writes:
> I'm a bit confused on this; if I could have a look at the code doing that
> it'd certainly help, but grepping for the warning string brings me a template
> file and not the actual code.
If by a template file you mean elf32.em, that is the actual code.
Some simple sed scripts are applied to the file, and the result is
compiled.
> Does anyone know beforehand where is the code in ld that searches and probes
> for shared objects in NATIVE_LIB_DIRS?
For shared objects in general, genscripts.sh stuffs the value of
NATIVE_LIB_DIRS into script files which will wind up in the
ld/ldscripts directory in your build directory. The values in
NATIVE_LIB_DIRS will appear as calls to SEARCH_DIR in the linker
scripts. Those calls will be passed to ldfile_add_library_path().
Later, ldfile_open_file_search() will call
gld${EMULATION_NAME}_open_dynamic_archive() (in elf32.em) for each
entry in SEARCH_DIR. That function is responsible for finding a
shared object.
However, this warning:
ld: warning: ld.so.1, needed by /lib/libc.so.1, not found (try using -rpath or -rpath-link)
indicates a search for a dependent shared library. This is not done
in the same way. It is done in gld${EMULATION_NAME}_after_open() in
elf32.em after the linker determines which dependent shared libraries
are required.
In that function, look for the loop which begins
for (search = search_head; search != NULL; search = search->next)
That looks through the entries made by ldfile_add_library_path().
Ian