linking against an alternate ld.so

[Matthew A. R. Sherian]

Kai Ruottu <kai.ruottu <at> wippies.com> writes:


> RTFM :
> 
> http://sourceware.org/binutils/docs/ld/Options.html#Options
> 
> For instance :
> 
> --dynamic-linker file
>      Set the name of the dynamic linker. This is only meaningful when
>      generating dynamically linked ELF executables. The default dynamic
>      linker is normally correct; don't use this unless you know what you
>      are doing.
> 
> for changing the place of 'ld.so'. Another and much quicker way to learn
> "usual options" in GNU tools is to try the '--help' option, for
> instance:
> 
>    ld --help
> 
> Setting the primary search place for the shared libs (besides the
> dynamic linker aka 'program interpreter') at runtime should succeed
> with the option '--rpath <directory>'. Meanwhile the '--rpath-link
> <directory>' will control the linktime situation. The '--help' should
> give all the previous options with a short explanation.
> 
> The special GCC's 'specs' file may be the right place to set these
> options being the defaults. Just editing it (without breaking its
> rigid scheme) should succeed easily. For instance there should be
> the original '--dynamic-linker /lib/ld.so' to be changed...
> 

Thanks for clearing this PEBKAC up for me. In addition, in case anyone out there
travel down a similar rabbit-hole. When building glibc/gcc/binutils there is a
minor "gotcha" within binutils ld/genscripts.sh fails to honor the various and
sundry library path one supplies. Internally LIB_PATH is used. In order to
suppress the system-dirs showing up in my objects I used
LIB_DIR=${LD_LIBRARY_PATH}. Where LD_LIBRARY_PATH is, of course, a list of
libdirs that exclude the system libdirs.