Re: Problematic linking between glibc and shared libgcc

[Russ Allbery <rra at stanford dot edu>]

I've been trying to stay quiet on this, since I don't have a firm
understanding of what's being done and how exactly it's going to work (and
many of the messages from Mark have been reassuring), but I think there
are some serious misconceptions of how gcc is used by at least some of its
end users at work in at least this message.

Phil Edwards <pedwards@disaster.jaj.com> writes:
> 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.

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.

We also routinely compile things with our site-wide gcc installation that
are later used on servers that don't necessarily mount AFS.  (We use GCC
by preference as our default compiler for all free/open source software,
in large part because it behaves consistently across multiple platforms
and some software is written expecting GCC extensions.)  We generally do
*not* want those programs to be built static (in fact, it's impossible to
build binaries completely static on Solaris if they use networking calls).
We do, obviously, want them to be linked statically against libgcc given
that situation.

I think the defaults that Mark describes makes sense, and I'm reassured
that regular C binaries won't be linked shared.  I'm a little worried
about what circumstances will cause binaries to be linked against a shared
libgcc for plain C still, though; if I'm compiling against shared
libraries on local disk in /usr/local, I don't want that to suddenly
magically add a shared library dependency on a library located in AFS.

I mostly care about the C compiler; I'm comfortable with C++ being more
aggressive about linking shared because C++ is generally only used by
students and projects and in that case it's reasonable to tell people that
if they build with AFS compilers, they'll need shared libraries out of AFS
to run their code.  But C isn't currently broken in my experience, and I'd
really rather not see it broken by a fix for C++.

> 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?)

> 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.)

> or LD_LIBRARY_PATH

We have a site policy against using LD_LIBRARY_PATH.  It causes way too
many spurious failures, is unreliable in its behavior, doesn't work with
setuid binaries, is stripped by many programs due to security constraints,
and is basically a *horrid* way of fixing anything apart from ugly hacks
to get badly written closed-source applications working.

Our users by and large do not have LD_LIBRARY_PATH set and I'll fight
tooth and nail against changing that.

> or -R or -rpath

Makefiles for existing software don't do this; do we now have to try to
teach users to compile with special flags?  Plus this has the same problem
as LD_RUN_PATH.

> or configuring with -static-libgcc

If the choice is breaking C++ or breaking C, I'll happily break C++ in an
instant, but it bothers me that we'd have to make that sort of tradeoff.

> 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?

> The LD*PATH variables are *quite* often going to be required anyway for
> other programs,

This isn't correct in the case of LD_LIBRARY_PATH.  LD_LIBRARY_PATH is
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.

I appreciate the problems that a shared libgcc is trying to solve, and I'm
certainly in favor of solving them, but it's really important for straight
C compiles to not be hurt by this mechanism.  If the shared library that
one is linking against depends on a shared libgcc, it's quite reasonable
for the resulting binary to also depend on a shared libgcc, but my *ideal*
world would have that be the only time that any C binary depends on a
shared libgcc (only if it is linking with shared libraries with a
dependency on a shared libgcc).

I don't know how feasible that would be.  :/  I have a sneaking suspicion
that it would require more linker magic than is readily available.

To give an idea of severity for my single data point, this is potentially
a show-stopper level of problem that would prevent us from deploying GCC
3.0.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>