This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC vs GLIBC: why this stance, Drepper ?!?
- To: "H . J . Lu" <hjl at lucon dot org>
- Subject: Re: GCC vs GLIBC: why this stance, Drepper ?!?
- From: Alexandre Oliva <aoliva at redhat dot com>
- Date: 02 Jul 2001 11:04:58 -0300
- Cc: Zack Weinberg <zackw at Stanford dot EDU>, gcc at gcc dot gnu dot org, libc-alpha at sources dot redhat dot com dot com
- Organization: GCC Team, Red Hat
- References: <20010630155951.B17670@lucon.org><20010630172344.B10718@stanford.edu> <20010630222620.B22998@lucon.org><orzoaoeof7.fsf@guarana.lsd.ic.unicamp.br><20010701084451.A1699@lucon.org>
On Jul 1, 2001, "H . J . Lu" <hjl@lucon.org> wrote:
> If I told you putting libgcc_s.so in /usr/local/lib didn't work too
> well or might override the one in /lib when there is libgcc_s.so in
> /lib, would you believe me?
I can see how this could be the case: if the user added /usr/local/lib
to /etc/ld.so.conf or to LD_LIBRARY_PATH. But then, it's the user's
choice, isn't it? It's not like GCC gets out of its way to make sure
it breaks the user's system. In fact, it doesn't even get programs
created with it to search for its own libgcc_s.so: it defers the
decision to the user. Whether this is a problem, I don't know. I
dislike having to set LD_LIBRARY_PATH or having to mess with
/etc/ld.so.conf to get programs to work, but there are people who
think this is the right thing to do, and I value their arguments. I'm
afraid there's no perfect solution.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist *Please* write to mailing lists, not to me