This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Part of] your Dec., 4th change to libf2c/Makefile.in.


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]