From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3747 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: Thu, 25 Jul 2013 19:59:55 +0300 Message-ID: <20130725195955.25cbc101@vostro> References: <20130724200221.GA4256@brightrain.aerifal.cx> <20130725104459.3c29fc34@vostro> <20130725161654.GH4284@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 1374771576 1081 80.91.229.3 (25 Jul 2013 16:59:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Jul 2013 16:59:36 +0000 (UTC) Cc: dalias@aerifal.cx To: musl@lists.openwall.com Original-X-From: musl-return-3751-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 25 18:59:39 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 1V2Ot7-0005lg-E2 for gllmg-musl@plane.gmane.org; Thu, 25 Jul 2013 18:59:37 +0200 Original-Received: (qmail 23787 invoked by uid 550); 25 Jul 2013 16:59:36 -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 23779 invoked from network); 25 Jul 2013 16:59:36 -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=y8KevJ1Ym5lVJ8h/Tjw2QHNZX2SwPnjvyPIQ2ZUvW3Q=; b=FB0beM32QnIW8GHrUGTD7QINnFAvpMK75lp+OZsM/8ELzQd46fpMeIoIaW52f8A3Ta 6bXqB1CYaiZDIqIemsQa0FBnLtsoqBNSlYC+tup3CrSq7/lA00ni2e5GlowXvBM6vrRi p+fjSXgDEVIH63fcijGzlokyLl202LIsw3tUnV8rdX7WkMdFfWSuuRXyAPBignbgrvwK qYUl5gcvhaM7/cx4la0b1gW8nLwTbCt9/3+9TWY6F+HYFVbhZZbG58kyhbqER+ldsE7d cn63KVvIqmy4VnIdPbigYAa2tdU47mqLthqHXxsVTVIH0ogAq7nPQAeWGeiNdVFXm5no 8f7Q== X-Received: by 10.14.5.68 with SMTP id 44mr5957713eek.141.1374771564890; Thu, 25 Jul 2013 09:59:24 -0700 (PDT) Original-Sender: =?UTF-8?Q?Timo_Ter=C3=A4s?= In-Reply-To: <20130725161654.GH4284@brightrain.aerifal.cx> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.20; i686-pc-linux-gnu) Xref: news.gmane.org gmane.linux.lib.musl.general:3747 Archived-At: 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. > What's affected by the C++ ABI compatibility changes is the ABI > between C++ applications and third-party libraries built against > musl's headers. As far as I know, there is no decent way around this > with versioning (library versioning or symbol versioning). There are > two ways this type of ABI linkage can come into play: > > - When the size of a type is not relevant to the interface between > libc and its caller, but affects the size of structs containing the > type, which another library might define and use as part of its > interface with its caller. > > - When the C++ compiler encodes the exact underlying type (for > non-aggregates) or the struct/union/enum tag into the mangled > symbol name for functions which take the type as an argument, and > both the caller and callee have to agree or you'll get unsatisfied > symbol references. > > Because C++ ABI is so fragile, musl has not had an official C++ ABI > until now. In fact, it's changed in subtle ways several times already > this year due to other bugs found, where musl's idea of a type's > identity disagreed with the compiler's idea of what it should be for > the particular psABI. (These needed to be fixed because they affect > things like printf format string warnings, and, for wchar_t, size_t, > ptrdiff_t, and perhaps a few others, they really need to match the > type of certain expressions (L"x", sizeof(x), p1-p2)). While > compatibility with C++ libraries built against glibc is part of the > motivation of the ABI-compat changes recently made, and equally > important aspect is just _stabilizing_ the ABI. By having a target ABI > to match (and test that we match), it's easy to know we don't have > lingering type mismatch bugs and thus that we won't need to break the > C++ ABI in the future. > > I apologize that the lack of C++ ABI stability was not warned about > prominently in previous releases. If you (or anyone else) have > deployed packages that you think will break, I can look into adding a > layer in the dynamic linker that would, when a C++ symbol lookup > fails, try substituting differently-mangled symbols which differ from > the desired one only in the nominal identity of the type but not in > its size or representation. This would not be too hard, but unless > it's needed, it's probably a bad idea. Full agree. And no, no need for the symbol name "re"-mangling hack. Still working on my initial build. > Finally, please note that any breakage from the C++ ABI changes will > be unresolved symbol errors at startup, not application misbehavior. Yes. I figured this. And it would be namely on the C++ libraries. Not on musl itself, as the musl symbols never changed. It's just C++ compiler's perception of the type names. > > Relatedly, commit f389c4984a (make the dynamic linker find its path > > file relative to its own location) introduced the armeb, armhf > > variants. Fundamentally, these are distribution specific names. I > > believe debian has/had armeb (big-endian OABI; being retired), arm > > (little-endian OABI; dead port), armel (little-endian EABI), and now > > armhf (little-endian EABI with hard-float). But these are by no > > means standard. While it is good that LDSO_ARCH gets good default > > with this distinguished. It should be allowed to be overridden by > > distributions. > > > > So basically I'd like to give at configure time: > > DISTRO_ARCH=armel > > Why? The goal isn't to match the distro's naming. It's to have a > unified name for any musl-linked binaries using this arch, so that if > you move them from one system to another (possibly with different > distro) they still work. The arch and subarch names used are unique > within the "ld-musl-..." namespace, so there's no danger of them > conflicting with other things in the distro. If you would prefer > different names, I would be happy to consider changing them at this > point (since there hasn't been a release with them anyway). However, I > think it's really counter-productive to use distro-specific PT_INTERP. > All that does is prevent someone from using your musl binaries on > another distro, or vice versa; the ability to do that is intended to > be one of musl's advantages over glibc. Well, now that you've added most needed subarches, I'm probably ok. I was just anticipating that if toolchain gets new feature affecting ABI, you need to track those all. But if you aim universal compatibility then this needs to be done. I guess there will not be insane amount of subarches, but you never know about future. - Timo