This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: A completely different approach to EH runtime


"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
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.
It seems like the ld -rpath mechanism can be used (though I do
recall some discussion as to why using -rpath was problemtical).

> Taking into
> account DSO and dlopen, I doubt 2 libgcc_s.so is a good idea.

Of it is not a good idea for a normal system, but it is perfectly
reasonable for a system where someone has compiled and installed
their own copy of gcc.  The alternatives are worse.

> as I said before, it is the same thing to have 2 libc.so.6 under
> Linux.

Yes.

> Unless both are provided by the distribution maker, it won't
> work very well since ld.so won't know which one is the right one.

The problem is again handled by a well-defined and sane search order.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]