Re: Problematic linking between glibc and shared libgcc

[Phil Edwards <pedwards at disaster dot jaj dot com>]

On Mon, Feb 19, 2001 at 12:17:54PM -0700, Eric W. Biederman wrote:
> The problem is this installs a half broken GCC.  In particular you the
> can't compile any program with GCC, and have it run before /usr/local
> is mounted.  As a secondary compiler on a unix system from a big
> vendor this is likely sane breakage, but it is still installing a broken gcc.

It's not even broken.  Very few admins need to add new programs to be
run that early in the boot process; those that do are not going to use a
secondary compiler, or if they do they will most likely link it statically.
You shouldn't use that as a scenario to justify dumping things into the
system directories.

I fail to see what's so difficult about using crle(1) or setting LD_RUN_PATH
or LD_LIBRARY_PATH or -R or -rpath or configuring with -static-libgcc or
whatever -- and only needing to do it *once*, heck, do it in the specs file
if you like -- and being done with it.  The LD*PATH variables are *quite*
often going to be required anyway for other programs, in which case this
is all transparent.  Any of these approaches strikes me as being cleaner
than placing third-party libraries into system directories.

Just my two cents.  Feel free to ignore them.


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.