This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [Part of] your Dec., 4th change to libf2c/Makefile.in.
- From: Alexandre Oliva <aoliva at redhat dot com>
- To: Toon Moene <toon at moene dot indiv dot nluug dot nl>
- Cc: gcc at gcc dot gnu dot org
- Date: 01 Jan 2002 20:49:32 -0200
- Subject: Re: [Part of] your Dec., 4th change to libf2c/Makefile.in.
- Organization: GCC Team, Red Hat
- References: <20011230133758.2C21BF2E47@nile.gnat.com><orbsge0x68.fsf@free.redhat.lsd.ic.unicamp.br><3C321637.2CA868C3@moene.indiv.nluug.nl>
On Jan 1, 2002, Toon Moene <toon@moene.indiv.nluug.nl> wrote:
> Alhough the original shell command wasn't right, this one isn't either.
> The net effect of this change is that libg2c.so[0.[0.0]] now resides in
> ..../lib/gcc-lib/i686-pc-linux-gnu/3.1
> in stead of
> ..../lib
Which sounds just right to me. I don't see how putting shared
libraries in $(libdir) can possibly work in the presence of
multilibs. Perhaps we should have a hook that creates a soft-link
only for the main copy of the library? I really think that having
libgcc_s.so and any other libraries directly in $(libdir) is wrong,
precisely because of the multilib issue. We've always deferred the
tricks to get programs to find libraries at run-time to program
builders, so my change doesn't change the status quo. In fact, having
libg2c.so.0 installed in $(libdir) would only help avoid this if you
set prefix to /usr or /usr/local, whose lib subdirs are typically
searched by default, or add $(libdir) to /etc/ld.so.conf, in which
case you might add the correct, multilib-aware location as well.
--
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