[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 7 Mar 2013 20:10:10 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: musl vs. Debian policy
On Thu, Mar 07, 2013 at 05:03:26PM -0800, Isaac Dunham wrote:
> > > The apparent solution to this is to ship only the dynamic linker,
> > > since this is all we need (the dependency on libc.so is disregarded
> > > when it comes to running dynamically linked programs). But
> > > currently, actually doing this would be somewhat of a hack.
> > >
> > > Is there any prospect of installing lib/libc.so straight to
> > > ${LDSO_PATHNAME} ? I'm thinking it could be done via something like:
> >
> > This has been proposed before, and the main obstacle was build-system
> > difficulties if I remember right. I'd still like to consider doing it,
> > but it would be nice to be able to do it for its own sake rather than
> > for the sake of satisfying distro policy being applied where it
> > doesn't make sense. Maybe we can try to figure out Debian's stance
> > before we rush into making the change for their sake.
>
> I'm actually more interested in it for the reasons Debian gives
> (explained above) than "because Debian says that's how to do it."
The problem is that you don't understand that the reasons DON'T APPLY
to musl. libc.so is purely a filename for the "ld" command to find. It
has nothing to do with runtime or versioning. The only musl library
file that will be searched when loading applications is
/lib/ld-musl-$(ARCH).so.1, which DOES have a version number. The
version number is encoded in the PT_INTERP rather than a DT_NEEDED
header.
> Of course, the possibe side-effects if Debian packagers were to go
> about it their own way and ended up with a different linker name are
> also rather obnoxious. I realize that's not a very pressing issue,
> since there isn't an RFP or ITP yet.
I don't think this would happen.
> But my main point is to ask whether, if I prepare a patch that
> does the job, it would be welcome.
If the change is desirable for other reasons, which it might be (we
should review the old threads), then it may very well be accepted. If
the only purpose is making the scripts for packaging on Debian
simpler, I don't think that's a good justification for making a
change.
Overall I think there are probably reasons that ld.so should be the
real file and libc.so the symlink, but we need to evaluate them and
weigh them against any difficulties or incompatibilities they'll
create. I'd like to discuss these issues on their own rather than as
part of a Debian policy discussion.
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.
