Re: LinuxThreads soname
I'm copying this to linux-gcc and debian-devel since I feel it
deserves a wider audience. I hope you don't mind.
Ulrich Drepper writes:
> david@elo.sw.ods.com (David Engel) writes:
>
> > > We have this package for all the additional libraries: X, curses, ...
> > ^^^^^^^
> >
> > Did you mean "problem" here?
>
> Sure. Sorry.
>
> > If so, I know. They will all need new sonames.
>
> This is a severe problem. You certainly will coordanize with the
> other distribution providers.
Well, I don't speak for Debian officially, but yes, I am sure we will
work anyone else to ensure interoperability.
> > > It it worth this?
> >
> > IMO, yes. The current glibc is alpha. People using it before it is
> > officially released should expect some changes. You can't expect
> > everyone using the current, standard libraries to rebuild everything
> > overnight just so you can reuse the same sonames. There has to be a
> > reasonable transition period where binaries using glibc can coexist
> > with binaries using libc5. The only way that can happen is to use
> > non-conflicting sonames.
>
> I agree with you. The problem is that as soon as I release glibc-2.0
> more people will start using it and they do it by just recompiling
> the old packages and so will get the same sonames like for libc-5.
> So there will certainly be a mechanism to handle the problem of
> old libraries.
IMO, all we can do is educate the distributors and their users. If
users are brave enough to not use a distribution and build their own
system, they should be smart enough to know what they are doing.
> My concern is that that when this one little change now it will
> not help much and we could take us more time to come out with a
> reasonable new method.
>
> One possible solution I can see is that we add some hacks to ld.so
> (BTW: we'll probably use the name ld-linux.so.1 for the GNU ld.so
> since I will add some hacks to support old and new binaries).
OK, but after giving it some more thought, having glibc provide
replacements for ld-linux.so.1 and libdl.so.1 isn't that critical to
me anymore.
> We could add an extension where the user can define some soname which
> are searched for. If the binary which has to be loaded contains a
> reference for this library an implicit LD_LIBRARY_PATH definition
> is assumed. E.g.,
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> libc.so.4 /usr/libc4/lib
> libc.so.5 /usr/libc5/lib
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> I.e., if the dependency of the binary mentiones libc.so.5 the
> LD_LIBRARY_PATH specified by the user is extended (at the end)
> by /usr/libc5/lib.
>
> So everybody could just move the old libraries in /usr/libc5/lib
> and the new will be placed in /lib, /usr/lib etc. So everything
> should work correctly without modification. Even modifying the
> specs file for gcc should be simple, so that still libc-5 binaries
> can be produced.
>
> Does this make sense for you?
Sense may not be the best word. I understand it fine, but it might be
over the heads of most users. Furthermore, my initial reaction is
that this is too much of a kiuge.
David
--
David Engel Optical Data Systems, Inc.
david@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: