[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130725163915.GI4284@brightrain.aerifal.cx>
Date: Thu, 25 Jul 2013 12:39:15 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Cc: nsz@...t70.net
Subject: Re: Preparing to release 0.9.12
On Thu, Jul 25, 2013 at 06:45:51PM +0300, Timo Teras wrote:
> > > Which would then make LDSO_ARCH, and SONAME accordingly. And with
> > > the soname version set, we could do proper binary ugprades (even
> > > when not everything is yet rebuilt).
> >
> > why do you care about the name of the loader?
> >
> > musl could use a random string, the only requirement
> > is that each abi has a unique identifier so there is
> > no collision
> >
> > if the name changes between distros then a simple
> > binary that only depends on libc becomes non-portable
>
> Well, when we have native tool chain, the loader name will have musl in
> it, and it's not portable to non-musl systems.
The binaries won't work without musl anyway.
> I can probably live with the default LDSO_ARCH name as long as so
> versioning is done properly. But I think it would still be useful to
We should figure out what "properly" means then. I think arranging for
the soname to contain the version for package management purposes, but
no other use, would probably meet your needs. Unlike glibc, musl aims
not to force you to update libc.so just because an application was
compiled against a newer version, but only if it actually needs a
feature in the newer version. (This is similar to how versioning works
with the kernel, BTW.) But distros often will want to impose this
requirement just to make sure a sufficiently new version is available
to have all features any of their packages might need.
> let it be overriden, in case distro decides to add patches that break
> ABI.
If the distro is doing this, the patch could (and should) change the
dynamic linker name at the same time it makes the other changes.
However I think you really over-estimate the need for breaking ABI.
It should not happen. glibc has not broken ABI in over a decade, and
aside from the C++ ABI (which is not part of the app-to-libc ABI),
musl has not broken ABI at all except to fix some types that were
defined so wrong that the associated interfaces didn't work.
If ABI changes were needed, moving to a new verison number for the
dynamic linker would be the right approach, I think. But I don't see
that happening anytime soon.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
