* musl 0.9.8 released @ 2012-11-27 2:49 Rich Felker 2012-11-27 11:31 ` Szabolcs Nagy ` (2 more replies) 0 siblings, 3 replies; 13+ messages in thread From: Rich Felker @ 2012-11-27 2:49 UTC (permalink / raw) To: musl Release announcement for musl 0.9.8: New PowerPC port and major bug fixes and improvements for the MIPS port. Coverage for more optional parts of POSIX including the thread priority scheduling option and stubs for unsupported functionality. Dynamic linker dl_iterate_phdr support. Various minor bugs and strict conformance issues have also been fixed and application compatibility improved. http://www.musl-libc.org/releases/musl-0.9.8.tar.gz As a post-release agenda, I'd like to first address things that have been in demand lately: - Proper MIPS softfloat support - x32 port - ether.h interfaces - %m modifier for scanf - Affinity/cpuset stuff And I have a few agenda items of my own: - Self-synchronized destruction of FILE streams (same issue all synchronization objects have had with self-synchronized destruction -- unlocking thread may not access memory after the destroying thread already got the lock). - Making stdio functions cancellable while waiting for locks. - Getting strace & gdb working properly with minimal patching. That's about it..hopefully the next release cycle won't take so long. Rich ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: musl 0.9.8 released 2012-11-27 2:49 musl 0.9.8 released Rich Felker @ 2012-11-27 11:31 ` Szabolcs Nagy 2012-11-27 14:46 ` Rich Felker 2012-11-28 2:43 ` Isaac Dunham 2012-12-03 13:11 ` Szabolcs Nagy 2 siblings, 1 reply; 13+ messages in thread From: Szabolcs Nagy @ 2012-11-27 11:31 UTC (permalink / raw) To: musl [-- Attachment #1: Type: text/plain, Size: 797 bytes --] * Rich Felker <dalias@aerifal.cx> [2012-11-26 21:49:58 -0500]: > As a post-release agenda, I'd like to first address things that have > been in demand lately: > > - Proper MIPS softfloat support > - x32 port > - ether.h interfaces > - %m modifier for scanf > - Affinity/cpuset stuff > > And I have a few agenda items of my own: > > - Self-synchronized destruction of FILE streams (same issue all > synchronization objects have had with self-synchronized > destruction -- unlocking thread may not access memory after the > destroying thread already got the lock). > - Making stdio functions cancellable while waiting for locks. > - Getting strace & gdb working properly with minimal patching. > + more math fixes :) i found minor restrict qualifier issues in some of the new interfaces [-- Attachment #2: restrict.diff --] [-- Type: text/x-diff, Size: 1691 bytes --] diff --git a/include/spawn.h b/include/spawn.h index 92b77f7..29c799e 100644 --- a/include/spawn.h +++ b/include/spawn.h @@ -57,8 +57,8 @@ int posix_spawnattr_getsigdefault(const posix_spawnattr_t *__restrict, sigset_t int posix_spawnattr_setschedparam(posix_spawnattr_t *__restrict, const struct sched_param *__restrict); int posix_spawnattr_getschedparam(const posix_spawnattr_t *__restrict, struct sched_param *__restrict); -int posix_spawnattr_setschedpolicy(posix_spawnattr_t *__restrict, int); -int posix_spawnattr_getschedpolicy(const posix_spawnattr_t *__restrict, int *); +int posix_spawnattr_setschedpolicy(posix_spawnattr_t *, int); +int posix_spawnattr_getschedpolicy(const posix_spawnattr_t *__restrict, int *__restrict); int posix_spawn_file_actions_init(posix_spawn_file_actions_t *); int posix_spawn_file_actions_destroy(posix_spawn_file_actions_t *); diff --git a/src/thread/pthread_attr_get.c b/src/thread/pthread_attr_get.c index e4650e4..ad913c5 100644 --- a/src/thread/pthread_attr_get.c +++ b/src/thread/pthread_attr_get.c @@ -11,7 +11,7 @@ int pthread_attr_getguardsize(const pthread_attr_t *restrict a, size_t *restrict return 0; } -int pthread_attr_getinheritsched(const pthread_attr_t *a, int *inherit) +int pthread_attr_getinheritsched(const pthread_attr_t *restrict a, int *restrict inherit) { *inherit = a->_a_sched; return 0; @@ -23,7 +23,7 @@ int pthread_attr_getschedparam(const pthread_attr_t *restrict a, struct sched_pa return 0; } -int pthread_attr_getschedpolicy(const pthread_attr_t *a, int *policy) +int pthread_attr_getschedpolicy(const pthread_attr_t *restrict a, int *restrict policy) { *policy = a->_a_policy; return 0; ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: musl 0.9.8 released 2012-11-27 11:31 ` Szabolcs Nagy @ 2012-11-27 14:46 ` Rich Felker 0 siblings, 0 replies; 13+ messages in thread From: Rich Felker @ 2012-11-27 14:46 UTC (permalink / raw) To: musl On Tue, Nov 27, 2012 at 12:31:02PM +0100, Szabolcs Nagy wrote: > * Rich Felker <dalias@aerifal.cx> [2012-11-26 21:49:58 -0500]: > > As a post-release agenda, I'd like to first address things that have > > been in demand lately: > > > > - Proper MIPS softfloat support > > - x32 port > > - ether.h interfaces > > - %m modifier for scanf > > - Affinity/cpuset stuff > > > > And I have a few agenda items of my own: > > > > - Self-synchronized destruction of FILE streams (same issue all > > synchronization objects have had with self-synchronized > > destruction -- unlocking thread may not access memory after the > > destroying thread already got the lock). > > - Making stdio functions cancellable while waiting for locks. > > - Getting strace & gdb working properly with minimal patching. > > > > + more math fixes :) :) > i found minor restrict qualifier issues in some of the new > interfaces Committed. Rich ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: musl 0.9.8 released 2012-11-27 2:49 musl 0.9.8 released Rich Felker 2012-11-27 11:31 ` Szabolcs Nagy @ 2012-11-28 2:43 ` Isaac Dunham 2012-11-28 3:39 ` Rich Felker 2012-12-03 13:11 ` Szabolcs Nagy 2 siblings, 1 reply; 13+ messages in thread From: Isaac Dunham @ 2012-11-28 2:43 UTC (permalink / raw) To: musl On Mon, 26 Nov 2012 21:49:58 -0500 Rich Felker <dalias@aerifal.cx> wrote: > > Release announcement for musl 0.9.8: > > New PowerPC port and major bug fixes and improvements for the MIPS > port. Coverage for more optional parts of POSIX including the > thread priority scheduling option and stubs for unsupported > functionality. Dynamic linker dl_iterate_phdr support. Various > minor bugs and strict conformance issues have also been fixed and > application compatibility improved. Thanks! > > http://www.musl-libc.org/releases/musl-0.9.8.tar.gz Mirrored at github.com/idunham/musl branch "master" > As a post-release agenda, I'd like to first address things that have > been in demand lately: > > - Proper MIPS softfloat support > - x32 port > - ether.h interfaces > - %m modifier for scanf > - Affinity/cpuset stuff > > And I have a few agenda items of my own: > > - Self-synchronized destruction of FILE streams (same issue all > synchronization objects have had with self-synchronized > destruction -- unlocking thread may not access memory after the > destroying thread already got the lock). > - Making stdio functions cancellable while waiting for locks. > - Getting strace & gdb working properly with minimal patching. > > That's about it..hopefully the next release cycle won't take so long. > > Rich All very good, and I don't think I've got any more to add... So I guess that leaves the subarches like so: x86: i486, x86_64 arm: arm(eb), armel mips: mips(32), mipsel(32) microblaze: microblaze (What's the status of microblazeel/microblazele? configure looks not to recognize it...) ppc: powerpc(32) Total arches: 6 Total subarches (distinct ABIs): 8-10 (depending on status of microblazeel and ABI compatability of armhf with armel) -planned subarches: mipsel32-sf, mips32-sf -planned arches: x32 -distant: mips64, mipsel64, ppc64 (I *think* Rich Pennington got these working, but they haven't been merged) -unsupported subarches: i386 It seems Debian's using aarch64-* for ARMv8. -- Isaac Dunham <idunham@lavabit.com> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: musl 0.9.8 released 2012-11-28 2:43 ` Isaac Dunham @ 2012-11-28 3:39 ` Rich Felker 2012-11-28 4:51 ` Isaac Dunham 0 siblings, 1 reply; 13+ messages in thread From: Rich Felker @ 2012-11-28 3:39 UTC (permalink / raw) To: musl On Tue, Nov 27, 2012 at 06:43:29PM -0800, Isaac Dunham wrote: > All very good, and I don't think I've got any more to add... > > So I guess that leaves the subarches like so: > x86: i486, x86_64 i386 and x86_64 aren't subarchs of a common arch. They're completely independent ISAs and cannot share any code. > arm: arm(eb), armel > mips: mips(32), mipsel(32) > microblaze: microblaze > (What's the status of microblazeel/microblazele? configure looks not > to recognize it...) It should work aside from configure not recognizing it. But I don't think it's been tested. > ppc: powerpc(32) > > Total arches: > 6 > Total subarches (distinct ABIs): > 8-10 (depending on status of microblazeel and ABI compatability of > armhf with armel) > > -planned subarches: mipsel32-sf, mips32-sf My idea for the names would be something like: mips, mipsel, mips-sf, mipsel-sf, ... Basically, the full arch name would be something along the lines of: arch[el|eb][-abivariant] which could be represented as $(ARCH)$(ENDIAN)$(ABIVARIANT), where only $(ARCH)$(ABIVARIANT) and $(ARCH) should be needed to search for asm files. But additional considerations need to be made for how the main arch dir with bits headers and internal headers would be selected. I don't think we want to duplicate entire arch trees for subarchs, but I also don't see how subarchs can get by with using the same set of headers unless we rely on the compiler to predefine macros that distinguish them. This is rather ugly but we're already partially relying on it for endianness varants. In the end, it might simply be the cleanest to just duplicate the trees, but use symlinks to eliminate most of the duplicate files. However, the interaction of that with install rules would have to be considered and the install rules might need revision. > -planned arches: x32 Yes. I think x32 (and mipsn32) probably need to be considered as separate archs, despite being the same ISAs as x86_64 (and mips64). > -distant: mips64, mipsel64, ppc64 (I *think* Rich Pennington got > these working, but they haven't been merged) Well, for a very limited definition of working. A majority of the actual *code* is done, but the headers were basically all just copies of the arm headers, meaning not much actually works. > -unsupported subarches: i386 ?? > It seems Debian's using aarch64-* for ARMv8. Yes, 64-bit arm is a new arch and it seems they used the name aarch64 instead of arm64 due to arm* being interpreted as 32-bit arm by many things.. Rich ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: musl 0.9.8 released 2012-11-28 3:39 ` Rich Felker @ 2012-11-28 4:51 ` Isaac Dunham 2012-11-28 13:05 ` Rich Felker 0 siblings, 1 reply; 13+ messages in thread From: Isaac Dunham @ 2012-11-28 4:51 UTC (permalink / raw) To: musl On Tue, 27 Nov 2012 22:39:48 -0500 Rich Felker <dalias@aerifal.cx> wrote: > On Tue, Nov 27, 2012 at 06:43:29PM -0800, Isaac Dunham wrote: > > arm: arm(eb), armel > > mips: mips(32), mipsel(32) > > microblaze: microblaze > > (What's the status of microblazeel/microblazele? configure looks not > > to recognize it...) > > It should work aside from configure not recognizing it. But I don't > think it's been tested. > > > ppc: powerpc(32) > > > > Total arches: > > 6 > > Total subarches (distinct ABIs): > > 8-10 (depending on status of microblazeel and ABI compatability of > > armhf with armel) > > > > -planned subarches: mipsel32-sf, mips32-sf > > My idea for the names would be something like: mips, mipsel, mips-sf, > mipsel-sf, ... > Basically, the full arch name would be something along the lines of: > > arch[el|eb][-abivariant] > > which could be represented as $(ARCH)$(ENDIAN)$(ABIVARIANT), where > only $(ARCH)$(ABIVARIANT) and $(ARCH) should be needed to search for > asm files. But additional considerations need to be made for how the > main arch dir with bits headers and internal headers would be > selected. I don't think we want to duplicate entire arch trees for > subarchs, but I also don't see how subarchs can get by with using the > same set of headers unless we rely on the compiler to predefine macros > that distinguish them. This is rather ugly but we're already partially > relying on it for endianness varants. Where would the headers need to differ by subarch? I'm guessing this is mainly stuff like fenv? > In the end, it might simply be the cleanest to just duplicate the > trees, but use symlinks to eliminate most of the duplicate files. > However, the interaction of that with install rules would have to be > considered and the install rules might need revision. <snip> > > -unsupported subarches: i386 > > ?? The 80386 processor, as opposed to 80486. # On x86, make sure we don't have incompatible instruction set # extensions enabled by default. This is bad for making static binaries. # We cheat and use i486 rather than i386 because i386 really does not # work anyway (issues with atomic ops). Also, I can't seem to find it now, but somewhere I heard that upstream gcc and/or glibc with the "i386-linux-*" triplet has some incompatability with "i486-linux-*". IIRC, I heard that some distros patch this to treat i386-linux-* as if it meant i486. But, I can't trace the source for that claim, so don't count on it... > > It seems Debian's using aarch64-* for ARMv8. > > Yes, 64-bit arm is a new arch and it seems they used the name aarch64 > instead of arm64 due to arm* being interpreted as 32-bit arm by many > things.. > ie, due to the insane number of ABIs and triplets that ARM has? arm (bigendian/OABI), armeabi (bigendian: armeb), armel (littleendian variant of EABI), armhf (armel + vfp3) -- Isaac Dunham <idunham@lavabit.com> ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: musl 0.9.8 released 2012-11-28 4:51 ` Isaac Dunham @ 2012-11-28 13:05 ` Rich Felker 2012-11-28 21:35 ` Rob Landley 0 siblings, 1 reply; 13+ messages in thread From: Rich Felker @ 2012-11-28 13:05 UTC (permalink / raw) To: musl On Tue, Nov 27, 2012 at 08:51:16PM -0800, Isaac Dunham wrote: > > > -planned subarches: mipsel32-sf, mips32-sf > > > > My idea for the names would be something like: mips, mipsel, mips-sf, > > mipsel-sf, ... > > > Basically, the full arch name would be something along the lines of: > > > > arch[el|eb][-abivariant] > > > > which could be represented as $(ARCH)$(ENDIAN)$(ABIVARIANT), where > > only $(ARCH)$(ABIVARIANT) and $(ARCH) should be needed to search for > > asm files. But additional considerations need to be made for how the > > main arch dir with bits headers and internal headers would be > > selected. I don't think we want to duplicate entire arch trees for > > subarchs, but I also don't see how subarchs can get by with using the > > same set of headers unless we rely on the compiler to predefine macros > > that distinguish them. This is rather ugly but we're already partially > > relying on it for endianness varants. > > Where would the headers need to differ by subarch? > I'm guessing this is mainly stuff like fenv? Yes, probably the floating-point headers are the main places: fenv.h, float.h, and math.h. > > > -unsupported subarches: i386 > > > > ?? > The 80386 processor, as opposed to 80486. > > # On x86, make sure we don't have incompatible instruction set > # extensions enabled by default. This is bad for making static binaries. > # We cheat and use i486 rather than i386 because i386 really does not > # work anyway (issues with atomic ops). This is fairly comparable to the mips1 issue and the need for ll/sc emulation by the kernel. i386 is just fundamentally lacking in a way that makes multi-tasking/multi-threading not workable with the POSIX apis for it. The kernel should be emulating 'lock cmpxchg', like it does ll/sc for mips1, and if it did, 386 would work fine. But apparently nobody cares anyway.. > Also, I can't seem to find it now, but somewhere I heard that > upstream gcc and/or glibc with the "i386-linux-*" triplet has some > incompatability with "i486-linux-*". IIRC, I heard that some distros > patch this to treat i386-linux-* as if it meant i486. > But, I can't trace the source for that claim, so don't count on it... This doesn't make any sense to me. > > > It seems Debian's using aarch64-* for ARMv8. > > > > Yes, 64-bit arm is a new arch and it seems they used the name aarch64 > > instead of arm64 due to arm* being interpreted as 32-bit arm by many > > things.. > > > ie, due to the insane number of ABIs and triplets that ARM has? > arm (bigendian/OABI), armeabi (bigendian: armeb), armel > (littleendian variant of EABI), armhf (armel + vfp3) :-) Rich ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: musl 0.9.8 released 2012-11-28 13:05 ` Rich Felker @ 2012-11-28 21:35 ` Rob Landley 2012-11-28 23:53 ` Rich Felker 0 siblings, 1 reply; 13+ messages in thread From: Rob Landley @ 2012-11-28 21:35 UTC (permalink / raw) To: musl On 11/28/2012 07:05:07 AM, Rich Felker wrote: > This is fairly comparable to the mips1 issue and the need for ll/sc > emulation by the kernel. i386 is just fundamentally lacking in a way > that makes multi-tasking/multi-threading not workable with the POSIX > apis for it. The kernel should be emulating 'lock cmpxchg', like it > does ll/sc for mips1, and if it did, 386 would work fine. But > apparently nobody cares anyway.. Actually this just got removed literally today: https://lkml.org/lkml/2012/11/28/445 If I recall, there was a longish discussion that boiled down to nobody could find actual 386 hardware still in use to test any of this with. Technically intel still made them until 5 years ago, but for aerospace and such rather than use in general purpose computers: http://www.reghardware.com/2006/05/18/intel_cans_386_486_960_cpus/ Rob ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: musl 0.9.8 released 2012-11-28 21:35 ` Rob Landley @ 2012-11-28 23:53 ` Rich Felker 2012-11-29 0:52 ` Rob Landley 0 siblings, 1 reply; 13+ messages in thread From: Rich Felker @ 2012-11-28 23:53 UTC (permalink / raw) To: musl On Wed, Nov 28, 2012 at 03:35:56PM -0600, Rob Landley wrote: > On 11/28/2012 07:05:07 AM, Rich Felker wrote: > >This is fairly comparable to the mips1 issue and the need for ll/sc > >emulation by the kernel. i386 is just fundamentally lacking in a way > >that makes multi-tasking/multi-threading not workable with the POSIX > >apis for it. The kernel should be emulating 'lock cmpxchg', like it > >does ll/sc for mips1, and if it did, 386 would work fine. But > >apparently nobody cares anyway.. > > Actually this just got removed literally today: > > https://lkml.org/lkml/2012/11/28/445 *sigh* that's frustrating. > If I recall, there was a longish discussion that boiled down to > nobody could find actual 386 hardware still in use to test any of > this with. It would be easy to test on qemu. I even have a 386 board I could set back up and test... Rich ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: musl 0.9.8 released 2012-11-28 23:53 ` Rich Felker @ 2012-11-29 0:52 ` Rob Landley 0 siblings, 0 replies; 13+ messages in thread From: Rob Landley @ 2012-11-29 0:52 UTC (permalink / raw) To: musl; +Cc: musl On 11/28/2012 05:53:04 PM, Rich Felker wrote: > On Wed, Nov 28, 2012 at 03:35:56PM -0600, Rob Landley wrote: > > On 11/28/2012 07:05:07 AM, Rich Felker wrote: > > >This is fairly comparable to the mips1 issue and the need for ll/sc > > >emulation by the kernel. i386 is just fundamentally lacking in a > way > > >that makes multi-tasking/multi-threading not workable with the > POSIX > > >apis for it. The kernel should be emulating 'lock cmpxchg', like it > > >does ll/sc for mips1, and if it did, 386 would work fine. But > > >apparently nobody cares anyway.. > > > > Actually this just got removed literally today: > > > > https://lkml.org/lkml/2012/11/28/445 > > *sigh* that's frustrating. Turns out I was wrong, the patch series hasn't been merged yet, it's just an RFC. (I only skim linux-kernel these days, too much traffic.) If you wanted to speak against it, the thread starts here: http://lkml.indiana.edu/hypermail/linux/kernel/1211.3/02304.html Rob ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: musl 0.9.8 released 2012-11-27 2:49 musl 0.9.8 released Rich Felker 2012-11-27 11:31 ` Szabolcs Nagy 2012-11-28 2:43 ` Isaac Dunham @ 2012-12-03 13:11 ` Szabolcs Nagy 2012-12-03 17:30 ` Rich Felker 2 siblings, 1 reply; 13+ messages in thread From: Szabolcs Nagy @ 2012-12-03 13:11 UTC (permalink / raw) To: musl * Rich Felker <dalias@aerifal.cx> [2012-11-26 21:49:58 -0500]: > As a post-release agenda, I'd like to first address things that have > been in demand lately: > > - Proper MIPS softfloat support > - x32 port > - ether.h interfaces > - %m modifier for scanf > - Affinity/cpuset stuff > > And I have a few agenda items of my own: > > - Self-synchronized destruction of FILE streams (same issue all > synchronization objects have had with self-synchronized > destruction -- unlocking thread may not access memory after the > destroying thread already got the lock). > - Making stdio functions cancellable while waiting for locks. > - Getting strace & gdb working properly with minimal patching. > i just remembered that there was a request about tzdata support with proper zoneinfo parsing instead of just posix TZ ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: musl 0.9.8 released 2012-12-03 13:11 ` Szabolcs Nagy @ 2012-12-03 17:30 ` Rich Felker 2012-12-03 22:03 ` Szabolcs Nagy 0 siblings, 1 reply; 13+ messages in thread From: Rich Felker @ 2012-12-03 17:30 UTC (permalink / raw) To: musl On Mon, Dec 03, 2012 at 02:11:17PM +0100, Szabolcs Nagy wrote: > i just remembered that there was a request about tzdata support > with proper zoneinfo parsing instead of just posix TZ Yes. I'd forgotten about that. It doesn't necessarily need to be on the agenda for the next release cycle, but it definitely needs to be in the 1.0 wishlist. I think I'll post a revised 1.0 wishlist with possible time frames for each item.. As for zoneinfo support, what it basically amounts to is writing a single function that, given a time in seconds since the epoch, runs over the mmapped zoneinfo binary format file and returns the timezone offset at that moment. It might also need the ability to determine separately the DST and non-DST offsets for the year that time falls in (for use with mktime) -- this could be done via an extra argument to the function, like the tm_isdst field, with 3 possible values -- and the ability to get the DST and non-DST names of the timezone. Would you or anyone else be interested in taking a shot at writing such a function? I remember I looked at it a while back and it didn't seem so hard, but the zoneinfo file format was really ugly with a lot of unnecessary indirection. Rich ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: musl 0.9.8 released 2012-12-03 17:30 ` Rich Felker @ 2012-12-03 22:03 ` Szabolcs Nagy 0 siblings, 0 replies; 13+ messages in thread From: Szabolcs Nagy @ 2012-12-03 22:03 UTC (permalink / raw) To: musl * Rich Felker <dalias@aerifal.cx> [2012-12-03 12:30:19 -0500]: > in the 1.0 wishlist. I think I'll post a revised 1.0 wishlist with > possible time frames for each item.. that will be useful > As for zoneinfo support, what it basically amounts to is writing a > single function that, given a time in seconds since the epoch, runs .. > Would you or anyone else be interested in taking a shot at writing > such a function? I remember I looked at it a while back and it didn't > seem so hard, but the zoneinfo file format was really ugly with a lot > of unnecessary indirection. i have other things queued now but can look into it later ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-12-03 22:03 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2012-11-27 2:49 musl 0.9.8 released Rich Felker 2012-11-27 11:31 ` Szabolcs Nagy 2012-11-27 14:46 ` Rich Felker 2012-11-28 2:43 ` Isaac Dunham 2012-11-28 3:39 ` Rich Felker 2012-11-28 4:51 ` Isaac Dunham 2012-11-28 13:05 ` Rich Felker 2012-11-28 21:35 ` Rob Landley 2012-11-28 23:53 ` Rich Felker 2012-11-29 0:52 ` Rob Landley 2012-12-03 13:11 ` Szabolcs Nagy 2012-12-03 17:30 ` Rich Felker 2012-12-03 22:03 ` Szabolcs Nagy
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/musl/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).