Re: ld doesn't check for ld.so.1 in /lib

[Ian Lance Taylor <ian at airs dot com>]

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