> > I am a firm believer that LD_LIBRARY_PATH is evil, certainly
> > at least dangerous and the
> > output binary from any compile should have an RPATH set to
> > ensure that the correct
> > libs are found that the developer wanted.
> >
> > Having said all that, is there a magic
> > LD_OPTIONS_INCANTATION=-Wl,-rpath=/usr/local/lib type thing
> > to set to ensure I get my RPATH ? I should point out
> > this is trivial to do in the Solaris world and perhaps I am
> > missing something really obvious here.
> >
> > Dennis
>
> crle ?
The manpage for the linker from binutils looks clear on this matter :
-rpath=dir
Add a directory to the runtime library search path. This is used
when linking an ELF executable with shared objects. All -rpath
arguments are concatenated and passed to the runtime linker, which
uses them to locate shared objects at runtime. The -rpath option
is also used when locating shared objects which are needed by
shared objects explicitly included in the link; see the description
of the -rpath-link option. If -rpath is not used when linking an
ELF executable, the contents of the environment variable
"LD_RUN_PATH" will be used if it is defined.
The -rpath option may also be used on SunOS. By default, on SunOS,
the linker will form a runtime search patch out of all the -L
options it is given. If a -rpath option is used, the runtime
search path will be formed exclusively using the -rpath options,
ignoring the -L options. This can be useful when using gcc, which
adds many -L options which may be on NFS mounted file systems.
For compatibility with other ELF linkers, if the -R option is
followed by a directory name, rather than a file name, it is
treated as the -rpath option.
-rpath-link=dir
When using ELF or SunOS, one shared library may require another.
This happens when an "ld -shared" link includes a shared library as
one of the input files.
When the linker encounters such a dependency when doing a non-
shared, non-relocatable link, it will automatically try to locate
the required shared library and include it in the link, if it is
not included explicitly. In such a case, the -rpath-link option
specifies the first set of directories to search. The -rpath-link
option may specify a sequence of directory names either by
specifying a list of names separated by colons, or by appearing
multiple times.
This option should be used with caution as it overrides the search
path that may have been hard compiled into a shared library. In
such a case it is possible to use unintentionally a different
search path than the runtime linker would do.
The linker uses the following search paths to locate required
shared libraries:
1. Any directories specified by -rpath-link options.
2. Any directories specified by -rpath options. The difference
between -rpath and -rpath-link is that directories specified by
-rpath options are included in the executable and used at
runtime, whereas the -rpath-link option is only effective at
link time. Searching -rpath in this way is only supported by
native linkers and cross linkers which have been configured
with the --with-sysroot option.
3. On an ELF system, for native linkers, if the -rpath and
-rpath-link options were not used, search the contents of the
environment variable "LD_RUN_PATH".
4. On SunOS, if the -rpath option was not used, search any
directories specified using -L options.
5. For a native linker, the search the contents of the environment
variable "LD_LIBRARY_PATH".
6. For a native ELF linker, the directories in "DT_RUNPATH" or
"DT_RPATH" of a shared library are searched for shared
libraries needed by it. The "DT_RPATH" entries are ignored if
"DT_RUNPATH" entries exist.
7. The default directories, normally /lib and /usr/lib.
8. For a native linker on an ELF system, if the file
/etc/ld.so.conf exists, the list of directories found in that
file.
If the required shared library is not found, the linker will issue
a warning and continue with the link.
----
So I will rebuild gcc with LD_RUN_PATH=/usr/local/lib:/usr/local/gcc4/lib64 and see what
I get.
Dennis
