[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 1 Feb 2013 21:38:33 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: musl 0.9.9 released
On Fri, Feb 01, 2013 at 06:23:40PM -0800, Isaac Dunham wrote:
> On Fri, 1 Feb 2013 02:10:53 -0500
> Rich Felker <dalias@...ifal.cx> wrote:
>
> > Hi all,
> >
> > I'm pleased to announce the release of musl 0.9.9. In some ways it's
> > less of a "big release" than I wanted while in other ways it's more.
> > The biggest aspect of this release which isn't reflected in the blurb
> > below is the record number of commits by persons other than myself,
> > particularly nsz and John Spencer. I didn't realize how much was going
> > to be new in this release until I sat down to write the change log and
> > looked back at how much they'd done. Thanks!
> >
>
> Glad to hear this. As usual, I've mirrored it at
> github.com/idunham/musl
>
> On a semi-related topic: my development repository is currently
> broken due to 5 corrupted objects (I think I have backups, though),
> so I tried salvaging it and ended up going through all the working
> branches making diffs.
Sorry to hear that -- hope restoring it goes well.
> The patches implement these changes:
>
> ABI: (much of this due to GregorR's patch)
> Add stub for logwtmp, sigsetmask
> Add getpt
> Some aliases, including __xpg_strerror_r and e(uid)access
> Add GNU error()
If error() is added, I don't think this should be considered ABI only.
It's a documented public interface in glibc and might as well be
visible in musl too if it's implemented...
> Add some BSD/GNU old math functions
Like..?
> Functionality:
> Add vm86/vm86old
Indeed, these should be added.
> Add fgetgrent (for heirloom-pkgtools) (patch same as the last time I sent it)
I'll look at it again.
> Fix strverscmp (patch same as the last time I sent it)
I'm not sure whether we got it into a fully-working state or not; the
conversation kinda died out last time. I'll review it again too. I
remember it didn't look quite like the algorithm I described/proposed,
but that doesn't mean it's wrong. It looked like it could at least use
some streamlining though.
> WIP:
> getifaddrs (I don't think this version will be useful, it's not netlink/IPv6 compatible)
Actually it might. I discovered the simplest way to add IPv6 support
is parsing /proc/net/if_inet6; it should be easy to tack that on to
your implementation. Easier than the netlink hell.
BTW I discovered this via "strace ifconfig" on busybox. :-)
> res_querydomain (not tested)-for lshw
Oh yeah, I need to look at that one again too. If I remember right,
the trouble I had reviewing it was that the documentation was utter
crap and didn't specify how it's supposed to behave except very
loosely, so it was hard for me to tell if it's handling the corner
cases the way it should.
> I'm expecting that much of the ABI stuff will not be desired, though
> it would be nice if the part for glibc-linked programs using correct
> C99/current POSIX functionality got merged.
Yes, I agree.
> It should probably move to #ifdef SHARED, though.
I'm a bit undecided on this. If it would also help linking .a
libraries compiled against glibc headers, it might be nice to have
these ugly aliases in the static libc.a too. On the other hand, static
libs built against glibc are not all that common.. :-)
> The vm86 stuff is something I'd like to see, for the sake of dosemu
> and some hardware utilities-this is something we'd need in order to
> replace klibc.
Agreed.
> fgetgrent is low priority and small, but I'll be carrying it if it
> doesn't get merged. It will not go in a separate library, since it
> pokes at libc's internals.
OK, this can probably be merged. I just need to look at it again..
> I could switch some of the ABI stuff to a glibc compatability
> LD_PRELOAD library (libglibc.so.6 ?).
I think the ugliness in the dynamic linker of detecting the need and
loading it is going to be worse than just putting the mess in libc.so.
> Rich, what would you like to see?
Keeping up this discussion, and nagging me again if too much time goes
by without progress on the above issues. If you'd like most of them
(except possibly the ABI mess) to be in the agenda for 0.9.10, I think
that would be a very reasonable goal.
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.
