From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2898 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl vs. Debian policy Date: Fri, 8 Mar 2013 20:23:54 -0500 Message-ID: <20130309012354.GA20323@brightrain.aerifal.cx> References: <20130306152913.59b2e776.idunham@lavabit.com> <20130307130424.GW20323@brightrain.aerifal.cx> <20130307170326.c8530e4b.idunham@lavabit.com> <20130308011010.GY20323@brightrain.aerifal.cx> <20130307200354.f489215c.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 1362792246 381 80.91.229.3 (9 Mar 2013 01:24:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Mar 2013 01:24:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2899-gllmg-musl=m.gmane.org@lists.openwall.com Sat Mar 09 02:24:31 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 1UE8WV-0006fo-2a for gllmg-musl@plane.gmane.org; Sat, 09 Mar 2013 02:24:31 +0100 Original-Received: (qmail 7836 invoked by uid 550); 9 Mar 2013 01:24:07 -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 7825 invoked from network); 9 Mar 2013 01:24:07 -0000 Content-Disposition: inline In-Reply-To: <20130307200354.f489215c.idunham@lavabit.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2898 Archived-At: On Thu, Mar 07, 2013 at 08:03:54PM -0800, Isaac Dunham wrote: > On Thu, 7 Mar 2013 20:10:10 -0500 > Rich Felker wrote: > > > > > 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. > > I understand that /lib/ld-musl-$(ARCH).so.1 is the only filename that a dynamically-linked binary sees. > However, if ld-musl-$(ARCH).so.1 is a symlink to libc.so, then anyone preparing a binary package must include libc.so in that package. > Incrementing the soversion (.so.1 -> .so.2) would not allow parallel installs. To illustrate, here's the layout I'm expecting with multiarch based on the current build system. > musl1: > /usr/lib/i486-linux-musl/libc.so > /lib/ld-musl-i386.so.1 => /usr/lib/i486-linux-musl/libc.so > > musl2 (if ABI breaks): > /usr/lib/i486-linux-musl/libc.so > /lib/ld-musl-i386.so.2 => /usr/lib/i486-linux-musl/libc.so This is mostly correct. I agree that for this usage the symlink should go in the opposite direction. Perhaps that's a good enough argument that the build system should install it to go in the opposite direction. However note that if "musl-1" and "musl-2" were really incompatible enough to need a different version number, sets of libraries linked against them would probably be likewise different, and it would probably not work to use the same lib directory for both... That's the whole reason we _don't_ want to be changing things. Rich