|
Message-ID: <20130726003851.GA20873@newbook> Date: Thu, 25 Jul 2013 17:38:51 -0700 From: Isaac <idunham@...abit.com> To: musl@...ts.openwall.com Subject: Re: Preparing to release 0.9.12 On Thu, Jul 25, 2013 at 07:59:55PM +0300, Timo Teras wrote: > On Thu, 25 Jul 2013 12:16:55 -0400 > Rich Felker <dalias@...ifal.cx> 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 <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. > > 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. -- Isaac Dunham
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.