Re: Problematic linking between glibc and shared libgcc

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

On Mon, Feb 19, 2001 at 04:11:19PM -0800, Russ Allbery wrote:
> Phil Edwards <pedwards@disaster.jaj.com> writes:
> > 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.
> 
> Dumping things into a system directory is not an option for our
> installation.  We install gcc in a central directory in AFS and it's used
> by innumerable machines not under our control that mount AFS.  The
> resulting compiled binaries can't depend on modifications of the system
> directories on local disk.

Then we're in agreement there; I do the same thing (more or less).


> > I fail to see what's so difficult about using crle(1)
> 
> Our users expect to be able to compile binaries and just have them work.
> I don't want to have to explain to them how to use a separate tool.  (And
> does crle exist on AIX, Digital Unix, HP-UX, IRIX, and all the other
> platforms we support?)

It's specific to one OS.  I suppose I should have written "crle or its
equivalent on whatever system you happen to be using," but I thought that
would be understood.

I would expect this to be a last resort.  Certianly my users wouldn't
understand crle or its equivalent on whatever system you happen to be using.


> > or setting LD_RUN_PATH
> 
> Setting LD_RUN_PATH to a directory in AFS is similarly not an option; it
> means that binaries with no other AFS dependencies may hang on startup if
> AFS is slow or down.  (Think NFS automounts if you're not familiar with
> AFS.)

I understand AFS.  The downside of pointing any of the *PATH variables to
anything over a network filesystem has been well documented in GNU tools
for years.  This why libraries (and only libs, not binaries) exist locally
on many machines; binaries and config files and whatnot are shared.

This argument never carried much weight with me personally.  If our
servers are slow or down, there are going to be problems regardless of
dynamic library dependancies.  I can imagine a networked environment in
which a slow network *only* affects dynamic libraries and nothing else,
but I've never seen one.


> > or LD_LIBRARY_PATH
> 
> We have a site policy against using LD_LIBRARY_PATH.

As do we.  I'm merely listing *options*.  *Options* means you don't have
to use them.  You can do whichever one works for you.  Some people, bless
their misguided hearts, prefer LD_LIBRARY_PATH for whatever reason, and
they can use it.  The only thing we can do is pray for them.  (And smack
them upside the head when they get close enough.)


> > or whatever -- and only needing to do it *once*, heck, do it in the
> > specs file if you like
> 
> Surely you don't expect the end users of GCC to be fiddling with the specs
> files, do you?

I got tired of typing smileys today.  I don't expect any human being to
be editing that file.  Guess the sarcasm didn't come through.


> only ever needed for broken, poorly written, poorly installed applications
> without source to fix them, and the best solution is frequently to simply
> not install such software in the first place.

Some of us don't have the option of taking the moral high road...


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.