Re: GCC vs GLIBC: why this stance, Drepper ?!?

[Marc Espie <espie at quatramaran dot ens dot fr>]

In article <10240000.994020372@warlock.codesourcery.com> you write:
>
>> It is the same thing as you are saying you can install another version
>> of the system shared C library, libc.so, in /usr/local/lib and expect
>> the whole machine will work reliably.
>
>Yes, I am saying that.  Isn't that true?  I didn't think the base
>system, installed by the vendor, was supposed to even know that /usr/local
>exists.  Now, users who put /usr/local in their PATH/LD_LIBRARY_PATH
>might get hosed -- but the system administrator shouldn't install stuff
>that doesn't work.

No, it's not true. The boundary between `system' and `user stuff' might
be more volatile than you think. You can have a base system in /usr,
a set of `ports' in /usr/local, plus some truely local stuff.
Then ld.conf will include /usr/local, at least.

Now, what do you do with gcc ? If it's in ports, it ends up configured 
in /usr/local, and potentially hoses up everything that's in /usr/local,
unless it plays nice.

Welcome to the wonderful world of shared libraries, where it's really
hard to make everything work correctly.

Actually, everything is not bleak. This will end up as always: local
patches to make things work.

But you definitely shouldn't assume you're an expert about what's going
on on every system gcc is likely to install upon. The idea that the
GNU stuff more or less `owns' the /usr/local namespace, so to speak, is
flaky at best, and is biting multiple times (this library issue is just
the last one on a long list). Actually, if gnu packages were to configure
in /usr/gnu by default (or /opt/gnu), this would be much better.
Not really that many practical changes, especially interaction-wise, but
at least it would be up front about what's going on.