From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2895 Path: news.gmane.org!not-for-mail From: Isaac Dunham Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl vs. Debian policy Date: Thu, 7 Mar 2013 20:03:54 -0800 Message-ID: <20130307200354.f489215c.idunham@lavabit.com> References: <20130306152913.59b2e776.idunham@lavabit.com> <20130307130424.GW20323@brightrain.aerifal.cx> <20130307170326.c8530e4b.idunham@lavabit.com> <20130308011010.GY20323@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1362715447 27429 80.91.229.3 (8 Mar 2013 04:04:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 8 Mar 2013 04:04:07 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2896-gllmg-musl=m.gmane.org@lists.openwall.com Fri Mar 08 05:04: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 1UDoXn-0006zZ-F8 for gllmg-musl@plane.gmane.org; Fri, 08 Mar 2013 05:04:31 +0100 Original-Received: (qmail 7388 invoked by uid 550); 8 Mar 2013 04:04:09 -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 7380 invoked from network); 8 Mar 2013 04:04:09 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=bd8S5PDvfedtc3UmtYdQ4TTBSokWQg97L3pv6z/GBhWVgx/hpOCkmdB3VuoVA2gKjaO8ezn34gC39+3LvcRA8JHqeH46V8kfQ5KeF9Ln4RRFC9yfCrinouv2OHTS/ZwNkDXhdD9TjW1ba9ZfqWzy/rEny3ObpnefAjP9z+aQfV0=; h=Date:From:To:Subject:Message-Id:In-Reply-To:References:X-Mailer:Mime-Version:Content-Type:Content-Transfer-Encoding; In-Reply-To: <20130308011010.GY20323@brightrain.aerifal.cx> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; i486-pc-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:2895 Archived-At: 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 I don't see any way for musl2 to be co-installed in a functional way, unless you change the triplet to i486-linux-musl2. Otherwise, you get the new ABI for both symlinks, breaking old binaries. A more conventional layout, with all libraries in /usr/lib or /lib, would have the same problem, but would not have the option of just changing the triplet/libdir. Even if you are not using a binary-package-based distro, a library with the incremented soversion would still break old libraries, since ld-musl-$(ARCH).so.1 points to the new libc.so. Is this analysis missing something? Thank you, Isaac Dunham