From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3745 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Preparing to release 0.9.12 Date: Thu, 25 Jul 2013 12:16:55 -0400 Message-ID: <20130725161654.GH4284@brightrain.aerifal.cx> References: <20130724200221.GA4256@brightrain.aerifal.cx> <20130725104459.3c29fc34@vostro> 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 1374769029 2810 80.91.229.3 (25 Jul 2013 16:17:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 25 Jul 2013 16:17:09 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3749-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jul 25 18:17:12 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 1V2OE0-0005EV-S2 for gllmg-musl@plane.gmane.org; Thu, 25 Jul 2013 18:17:08 +0200 Original-Received: (qmail 27938 invoked by uid 550); 25 Jul 2013 16:17: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 27930 invoked from network); 25 Jul 2013 16:17:07 -0000 Content-Disposition: inline In-Reply-To: <20130725104459.3c29fc34@vostro> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:3745 Archived-At: 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. 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. Finally, please note that any breakage from the C++ ABI changes will be unresolved symbol errors at startup, not application misbehavior. > 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. Rich