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, Richard Henderson <rth@redhat.com> wrote:

> On Tue, Jan 01, 2002 at 09:32:26PM -0200, Alexandre Oliva wrote:
>> But not all systems have a notion of SONAME...

> So what?  All we need is for it to work on the systems that
> (1) have shared libraries and (2) actually use multilibs.

As long as we don't introduce too much junk in the build system in
order to support this behavior.

> That's ia64-hpux, irix6, sparc64-solaris, and aix4.3.

> All except for the last use ELF, and so SONAME is supported.

> As for AIX, we could probably hack collect2 to change the
> library name as needed, which gets the transparency you want.

Changing the library name when you link *with* the library is a bad
idea, IMO.  I was just trying to show why I didn't like the change in
library name.  It would be perfect if we had the ability to link with
the library using its link-time name (i.e., -lfoo == libfoo.so), but,
by means of SONAME-like magic, get the correct multilib to be found at
run-time.  But I don't know whether this is possible on AIX.

> In any case, I'll claim that what you're doing right now 
> for libg2c is wrong based solely on the fact that it's not
> what we do for all of the other shared libraries.  Please
> install libg2c just like the rest of our runtime libraries.

We don't have a uniform handling of shared libraries at the moment.
We do the SONAME magic with libgcc_s, we do something different with
libstdc++-v3, and something else with libobjc.  Right now, libf2c does
exactly like libobjc, which was the library on which I based my change
to libf2c.

Doing the same as libstdc++-v3 is relatively easy, but it not as good
as what we do with libgcc_s.

Getting libtool to do the same as we do for libgcc_s is going to take
a bit of libtool hacking, to support (i) the notion of having
different link-time and run-time names (which, again, is not going to
be portable across all of the systems we support), so that we can add
the multilib identifier to the SONAME of a library and (ii) the
creation of run-time soft-links in directories other than the one in
which the library is installed.

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