[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130725161654.GH4284@brightrain.aerifal.cx>
Date: Thu, 25 Jul 2013 12:16:55 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Preparing to release 0.9.12
On Thu, Jul 25, 2013 at 10:44:59AM +0300, Timo Teras wrote:
> On Wed, 24 Jul 2013 16:02:21 -0400
> Rich Felker <dalias@...ifal.cx> 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
