From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3752 Path: news.gmane.org!not-for-mail From: Timo Teras Newsgroups: gmane.linux.lib.musl.general Subject: Re: Preparing to release 0.9.12 Date: Fri, 26 Jul 2013 08:13:27 +0300 Message-ID: <20130726081327.3d915b49@vostro> References: <20130724200221.GA4256@brightrain.aerifal.cx> <20130725104459.3c29fc34@vostro> <20130725161654.GH4284@brightrain.aerifal.cx> <20130725195955.25cbc101@vostro> <20130726003851.GA20873@newbook> 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 1374815587 3452 80.91.229.3 (26 Jul 2013 05:13:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Jul 2013 05:13:07 +0000 (UTC) Cc: idunham@lavabit.com To: musl@lists.openwall.com Original-X-From: musl-return-3756-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 26 07:13:10 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 1V2aKy-0003jn-SB for gllmg-musl@plane.gmane.org; Fri, 26 Jul 2013 07:13:08 +0200 Original-Received: (qmail 14207 invoked by uid 550); 26 Jul 2013 05:13:08 -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 14196 invoked from network); 26 Jul 2013 05:13:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:in-reply-to:references :x-mailer:mime-version:content-type:content-transfer-encoding; bh=fYoeSmoAsy/XWB11OxPgteJcHm7y1n6nTR740cw5cgU=; b=GnPMz0sVPPmvqVoJum0sIE5HrhMKSFoDt6UeNGSmqzx6IME6Sfpxo+YIAkaCo2aDIT cCXVjNbS8ypC0DVOCpjq0l/oOro4AGOhAdRXH4aalwO//Vzt0FFirH/AkHedOMNApb0f bo5iszHGN1T4EexYM56gHwlbMAN6eQUtKX5ckjep8gQUZ7d9k4I/ryADfiJbqW6a1Jlr 6uD04nck3c8z0Dje81Pqkd1SOywoGAqvYb8CSbU233dkC2x42WmaIrI4mgHmJn9hsrFq WcppbTNXXb8qb2/+Zke3AQ+eSfI94/XLGSer+hYg/kU951NEuGt0laO3KBunRpN4cbTp Gs3w== X-Received: by 10.14.149.141 with SMTP id x13mr45730711eej.77.1374815576269; Thu, 25 Jul 2013 22:12:56 -0700 (PDT) Original-Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= In-Reply-To: <20130726003851.GA20873@newbook> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.20; i686-pc-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:3752 Archived-At: On Thu, 25 Jul 2013 17:38:51 -0700 Isaac wrote: > On Thu, Jul 25, 2013 at 07:59:55PM +0300, Timo Teras wrote: > > On Thu, 25 Jul 2013 12:16:55 -0400 > > Rich Felker wrote: > > > > > On Thu, Jul 25, 2013 at 10:44:59AM +0300, Timo Teras wrote: > > > > On Wed, 24 Jul 2013 16:02:21 -0400 > > > > Rich Felker wrote: > > > > > > > > > The list of changes since 0.9.11 has grown quite large, and > > > > > although we haven't met some of the roadmap goals for 0.9.12, > > > > > others that were marked for 0.9.13 have already been > > > > > finished. So I think it's reasonable to aim to release very > > > > > soon now. There are still a few pending items I'd like to get > > > > > committed before the release: > > > > > > > > > > - orc's getaddrinfo fix for AF_UNSPEC with NULL hostname > > > > > - Andre's ARM memcpy optimizations > > > > > - New crt1.c code for adding PIE support for more archs > > > > > - MAYBE the symlink direction issue... > > > > > > > > Since the C++ ABI was fixed, it means that any current native > > > > musl toolchain will get C++ ABI breakage? > > > > > > > > In this case the symlink direction issue would help with > > > > smoother transitions. It would be also crucial to start using > > > > proper SONAME versioning, so we could handle binary upgrades > > > > smoothly. > > > > > > This would not help. The ABI between the application and musl's > > > libc.so has not changed since just after the initial public > > > release, except for some bugs that had arch-specific structures > > > laid out wrong, etc. -- and in this case, programs built before > > > the fix were not working at all anyway when using the affected > > > feature. > > > > The so versioning will not help for C++ related things. The most > > important use case I had in mind is that, package managers that use > > soversions for automatic dependencies, can insert proper "require > > version XXX or later of this .so". That is, if we built with musl > > X, we can detect that from .so, and record it. And later ensure > > that musl X-1 will not satisfy the newly built package's > > dependencies. Especially important when we are introducing new > > symbols. > > > On Debian, there's the "symbols" system; this lists all symbols with > the version they appeared in, and the tools look through the symbols > and find the lowest version providing all the symbols. > > But as a standard rule, _added_ symbols _do_ _not_ call for a new > SONAME, since they do not break the ABI. Correct. The usual way is: soname = . filename = . And then have symlink soname -> filename. This would allow side-by-side installation of different library versions if needed. But the "symbols" system looks interesting too. If doing that, the lib-version would be then. A good related read was (explains also the soname/filename concept): http://developer.ubuntu.com/packaging/html/libraries.html While SONAME we want to keep stable, and change only in the unlikely event of abi breakage. I think it'd be still nice allow easily the suffix to the generated file. Thanks, Timo