Date: Fri, 26 Jul 2013 08:13:27 +0300 From: Timo Teras <timo.teras@....fi> To: musl@...ts.openwall.com Cc: idunham@...abit.com Subject: Re: Preparing to release 0.9.12 On Thu, 25 Jul 2013 17:38:51 -0700 Isaac <idunham@...abit.com> 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 <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. Correct. The usual way is: soname = <lib-name>.<abiver> filename = <soname>.<lib-version> 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 <lib-version> suffix to the generated file. Thanks, Timo
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.