From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2894 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl vs. Debian policy Date: Thu, 7 Mar 2013 20:10:10 -0500 Message-ID: <20130308011010.GY20323@brightrain.aerifal.cx> References: <20130306152913.59b2e776.idunham@lavabit.com> <20130307130424.GW20323@brightrain.aerifal.cx> <20130307170326.c8530e4b.idunham@lavabit.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1362705025 8889 80.91.229.3 (8 Mar 2013 01:10:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Mar 2013 01:10:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2895-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 08 02:10:45 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1UDlpd-0003E9-D0 for gllmg-musl@plane.gmane.org; Fri, 08 Mar 2013 02:10:45 +0100 Original-Received: (qmail 21832 invoked by uid 550); 8 Mar 2013 01:10:23 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 21824 invoked from network); 8 Mar 2013 01:10:23 -0000 Content-Disposition: inline In-Reply-To: <20130307170326.c8530e4b.idunham@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2894 Archived-At: 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