Re: LinuxThreads soname
This thread died out before Christmas. I was busy with other things
and then went on vacation for a couple of weeks. I'm sure others were
in similar situations. Now that glibc 2.0 has officially been
released, it's extremely important, IMO, that we reach consensus on
this issue before chaos reigns in the Linux world.
To refresh everyone's memory, the issue is this. Glibc 2.0 uses an
soname of libc.so.6 under Linux to distinguish itself from the
previous version from H.J. Lu which used libc.so.5. This is all fine,
but what do we do about other libraries which are already in use with
libc5? Do we make sure everyone uses new sonames for these libraries
when they are built with libc6, or do we reuse the same sonames and
add hacks to the dynamic linkers to make them look in different
directories depending on whether libc5 or libc6 is being used?
David
On 21 Dec 1996, Ulrich Drepper wrote:
> David Holland <dholland@eecs.harvard.edu> writes:
>
> > This will only work if the library in question even has a reference
> > for libc.so.anything. Given the default behavior of ld, is it wise to
> > assume this?
>
> Do you ever saw a binary which is linked against some shared libs but
> not against libc.so.X? You see the other way round, linked statically
> against Motif but dynamically against libc.so. (BTW: I also don't use
> any distribution.)
>
> > I think (speaking as someone who doesn't use a distribution) a more
> > general solution would be a program to edit the soname references of
> > binaries, both libs and executables. And maybe to edit the soname
> > fields of libraries too.
>
> I would say this is only useful if it really turns out your above case
> is frequent. And perhaps this is even in this situation a backup
> solution. I really don't want to spend hours searching and changing
> all the binaries I haven't updated so far. The proposed method would
> automatically handle this.
>
> > Ugly, yes, but it would get the job done, and it's a
> > bit more general; it would allow taking care of a variety of other
> > transition cases.
>
> I find this solution much unlikely to be understood. It is not
> transparent. You always have to check what program was already
> changed. The approach I outlined would cure the problems in one
> strike. Simply move all old shared lib into a special directory
> (after adding this to the old ld.so's search patch), install glibc,
> mention the directory for old libc and run everything like before.
>
> -- Uli
> ---------------. drepper@cygnus.com ,-. Rubensstrasse 5
> Ulrich Drepper \ ,-------------------' \ 76149 Karlsruhe/Germany
> Cygnus Solutions `--' drepper@gnu.ai.mit.edu `------------------------
>
David Engel ODS Networks
david@sw.ods.com 1001 E. Arapaho Road
(972) 234-6400 Richardson, TX 75081
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: