A completely different approach to EH runtime

[H . J . Lu]

On Wed, Feb 21, 2001 at 03:26:36PM -0800, Per Bothner wrote:
> "H . J . Lu" <hjl@valinux.com> writes:
> 
> > Now you have 2 libgcc_s.so. Which one should ld.so use?
> 
> It depends on the specified flags and environment variables.  Programs
> installed in /bin or /sbin should search /lib first, and programs
> installed in /usr/bin and /usr/sbin should search /lib and /usr/lib
> before searching elsewhere.  This is assuming LD_LIBRARY_PATH is not
> specified; I'm agnostic as to whether LD_LIBRARY_PATH is checked for
> programs in these standard binary directories.  (Clearly suid programs
> should not check LD_LIBRARY_PATH!)  I'm also agnostic as to what the

We don't check LD_LIBRARY_PATH for suid programs.

> default search order should be for user programs, as long as it can be
> overridden by LD_LIBRARY_PATH.
> 
> The simplest search order consistent with these requirements is to
> search LD_LIBRARY_PATH, then directories specified by ld's -rpath,
> then /lib, then /usr/lib, then /usr/local/lib.
> 
> Consistent with this, it seems to me that if you compile and install
> gcc, libgcc should get installed in /usr/local/lib, or more generally
> in $prefix/lib.  The problem then is: If the user compiles a program
> using their private $prefix/bin/gcc, we want the resulting exevutable
> to use $prefix/lib/libgcc_s.so rather than /lib/libgcc_s.so, without
> requiring use of LD_LIBRARY_PATH.  That is a simple matter of
> recording the preferance for $prefix/lib/libgcc_s.so in the ELF
> executable, and having the dynamic linker use that preference.

Say I build a DSO, libfoo.so, with $prefix/bin/gcc. And I do

	handle = dlopen ("libfoo.so", ...);

from an executable, bar, built by /usr/bin/gcc. When I start bar,
/lib/libgcc_s.so is loaded into memory. Now when dlopen comes, which
libgcc_s.so should be used by libfoo.so? Since bar has already loaded
libgcc_s.so from /lib, it won't load $prefix/lib/libgcc_s.so. Now
libfoo.so is very upset unless /lib/libgcc_s.so is 100% compatible
with $prefix/lib/libgcc_s.so.

> It seems like the ld -rpath mechanism can be used (though I do
> recall some discussion as to why using -rpath was problemtical).

Yes. I don't like -rpath very much under Linux. Also it still doesn't
work with the dlopen case above.


-- 
H.J. Lu (hjl@valinux.com)