Re: confirmed working NPTL revision?
On Tuesday 16 September 2008 02:48:49 Matthieu CASTET wrote: Hi, Rob Landley a écrit : IIRC there have been some issues in the past... so, unless we are totally sure, we need to keep the working/stable and old linuxthreads.old. No, what we do is we keep the 0.9.29 tarball around and if people have bugs trying to use 0.9.30 they _report_ them to us. If they want to use the old threading code, they can use the old version of the library. If they want the new features, then they help us find (and fix) the new bugs. You mean adding in the 0.9.30 untested code ? There are currently two threading implementations in -svn, just as there were two in 0.9.29 and in 0.9.28 and for a few releases before that. Look in the General Library Settings menu, under threading support there's Use the older (stable) version of linuxthreads. The config symbol is LINUXTHREADS_OLD. This has nothing to do with NPTL, this has to do with using an obsolete version of the old Linuxthreads package, or using a newer version of the linuxthreads package. There's no reason to have two versions of _linuxthreads_, since NPTL will in theory eventually obsolete _both_ of them. Either we should say the newer one failed, remove it, or say the newer one works, remove the older one. I've had reports of the newer one working, so I'm inclined to remove the one that's _labeled_ OLD. Do you know if linuxthreads pass some thread regression tests (glibc one, ltp, ...) ? Nope. Would anyone like to test it? I've got a smoke test, but it doesn't look for strange edge cases and doesn't look at performance or size at all. Remeber that, even when merged, NPTL is available only for 3 archs at the time being. Who said anything about NPTL? Right now, in 0.9.29, there's LINUXTHREADS_OLD and there's a second implementation of Linuxthreads that most people haven't been testing because they're still on LINUXTHREADS_OLD. There's not much point in having two of these right now, and adding NPTL would make _three_. I'd like to keep it to no more than two, which means I need to yank one before NPTL goes in. I remember than 1 year ago, developers agree to drop LINUXTHREADS, because work should be done on nptl instead trying to fix LINUXTHREADS. [1] Good for them. More than 1 year ago the 0.9.30 release was imminent. It didn't happen. Yay NPTL branch, hopefully I'll live to see it. And I agree with that. If nptl merge happen soon there no point to do some extra work on LINUXTHREADS. I'm not talking about extra work, I'm saying there are two redundant implementations and one of them should go. Matthieu PS : if only companies selling uclibc could hire some developers to improve the mainstream version ... Yes and no: my understanding is that half the reason NPTL is in the state it's in was that sjhill refused to release his code until he got paid for it, by which point we had three competing implementations (but Erik had already promised sjhill his would go in first)... Hiring developers is nice, but it's not necessarily _simple_. [1] nptl is really missing on some arch to get faster thread switch, some mutex with prio inversion, ... *shrug* Rob ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
On Tuesday 16 September 2008 05:12:15 Will Newton wrote: On Tue, Sep 16, 2008 at 7:23 AM, Carmelo AMOROSO [EMAIL PROTECTED] wrote: 1) How platform specific is it? Fully, TLS relocations are different from one arch to another. 2) Does it actually have anything to do with nptl? Nothing, just dynamic linker, and obviously your compiler has to recognize the __thread keyword. I was under the impression that TLS support was a requirement of implementing NPTL, is that not the case? http://www.linux-mips.org/wiki/NPTL But NPTL is not a requirement for implementing TLS, and TLS is independently useful. Rob ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
Hi, Rob Landley a écrit : IIRC there have been some issues in the past... so, unless we are totally sure, we need to keep the working/stable and old linuxthreads.old. No, what we do is we keep the 0.9.29 tarball around and if people have bugs trying to use 0.9.30 they _report_ them to us. If they want to use the old threading code, they can use the old version of the library. If they want the new features, then they help us find (and fix) the new bugs. You mean adding in the 0.9.30 untested code ? Do you know if linuxthreads pass some thread regression tests (glibc one, ltp, ...) ? Remeber that, even when merged, NPTL is available only for 3 archs at the time being. Who said anything about NPTL? Right now, in 0.9.29, there's LINUXTHREADS_OLD and there's a second implementation of Linuxthreads that most people haven't been testing because they're still on LINUXTHREADS_OLD. There's not much point in having two of these right now, and adding NPTL would make _three_. I'd like to keep it to no more than two, which means I need to yank one before NPTL goes in. I remember than 1 year ago, developers agree to drop LINUXTHREADS, because work should be done on nptl instead trying to fix LINUXTHREADS. [1] And I agree with that. If nptl merge happen soon there no point to do some extra work on LINUXTHREADS. Matthieu PS : if only companies selling uclibc could hire some developers to improve the mainstream version ... [1] nptl is really missing on some arch to get faster thread switch, some mutex with prio inversion, ... ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
On Tue, Sep 16, 2008 at 7:23 AM, Carmelo AMOROSO [EMAIL PROTECTED] wrote: 1) How platform specific is it? Fully, TLS relocations are different from one arch to another. 2) Does it actually have anything to do with nptl? Nothing, just dynamic linker, and obviously your compiler has to recognize the __thread keyword. I was under the impression that TLS support was a requirement of implementing NPTL, is that not the case? http://www.linux-mips.org/wiki/NPTL ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
On Tue, Sep 16, 2008 at 8:48 AM, Matthieu CASTET [EMAIL PROTECTED] wrote: Who said anything about NPTL? Right now, in 0.9.29, there's LINUXTHREADS_OLD and there's a second implementation of Linuxthreads that most people haven't been testing because they're still on LINUXTHREADS_OLD. There's not much point in having two of these right now, and adding NPTL would make _three_. I'd like to keep it to no more than two, which means I need to yank one before NPTL goes in. I remember than 1 year ago, developers agree to drop LINUXTHREADS, because work should be done on nptl instead trying to fix LINUXTHREADS. [1] I voiced my objections at the time, I'm using LINUXTHREADS and it works for me. And I agree with that. If nptl merge happen soon there no point to do some extra work on LINUXTHREADS. LinuxThreads is the only option if you work on systems that use Linux 2.4. Implementing NPTL is a big task, not something that happens overnight and there are a number of architectures that are missing support for it at the moment. Matthieu PS : if only companies selling uclibc could hire some developers to improve the mainstream version ... [1] nptl is really missing on some arch to get faster thread switch, some mutex with prio inversion, ... ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
Rob Landley wrote: On Tuesday 16 September 2008 01:23:37 Carmelo AMOROSO wrote: 1) How platform specific is it? Fully, TLS relocations are different from one arch to another. Ok. 2) Does it actually have anything to do with nptl? Nothing, just dynamic linker, and obviously your compiler has to recognize the __thread keyword. I think we've got that part covered. What I'm thinking is that if TLS can be added to the main svn branch as a separate chunk, that's can be considered a partial merge (brings the NPTL and mainline branches somewhat closer), and it's small and separate enough to go into a 0.9.30 release. Honestly, I'd do a 0.9.30 right now without delaying further as a lot of peoples are asking for a new release since a long time. Works for me, except that I'm still doing mroe testing and I've got bugs to fix. Well, we could ship now with a -rc1. Adding bug fixes as someone have tests/fixes for them, and go ahead shortly with a -rc2, and so... in a tight loop. I do not expect to go over -rc5... just like kernel do... Since I haven't got the authority to tell people _not_ to check random changes into svn, what I may do is grab a snapshot of the svn archive, put it into a mercurial archive, call that -rc1, and then do bugfix-only changes to it until I get a 0.9.30-final. ... and after, yeah let's ship a stable 0.9.30. But let's do... don't we waste more time. We can worry about official after the release. :) We can have a branch as a development tree for adding TLS support but independently from NPTL merge... I'd like to do this after .30 release. In this way we will have already TLS for arm/mips/sh4 as part as the nptl work... and it can be used as a reference implementation. Ok. At this stage, having a separate branch for adding TLS support for other archs (which one... i386 only ?) , may be done in a separate branch or directly to the main stream. I never bother with branches in subversion. *shrug* Also, rather than have _three_ threading branches (once NPTL is added), I'd like to yank LINUXTHREADS_OLD before releasing a 0.9.30 if the newer stuff works for everybody. (And if it doesn't, I want bug reports.) I honestly have never used linuxthreads so I don't how it work. Like anything else, really. Here's a test program for threading I wrote, which passes data from one thread to another via a simple mailbox implementation using mutexes and event semaphores: http://landley.net/hg/firmware/file/tip/sources/native/src/thread-hello2.c It's basically hello world, but way complicated. IIRC there have been some issues in the past... so, unless we are totally sure, we need to keep the working/stable and old linuxthreads.old. No, what we do is we keep the 0.9.29 tarball around and if people have bugs trying to use 0.9.30 they _report_ them to us. If they want to use the old threading code, they can use the old version of the library. If they want the new features, then they help us find (and fix) the new bugs. It may be a solution... I' don't have the power to drop linuxthrad.old anyway... we need a wider agreement (Mike, Jocke, Bernhard, Bernd..others ?) Remeber that, even when merged, NPTL is available only for 3 archs at the time being. Who said anything about NPTL? Right now, in 0.9.29, there's LINUXTHREADS_OLD and there's a second implementation of Linuxthreads that most people haven't been testing because they're still on LINUXTHREADS_OLD. In this case I think you're right... we should push using it. There's not much point in having two of these right now, and adding NPTL would make _three_. I'd like to keep it to no more than two, which means I need to yank one before NPTL goes in. Rob Comments are welcome. Carmelo Rob Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
On Tue, Sep 16, 2008 at 12:28:19PM +0200, Carmelo AMOROSO wrote: Well, we could ship now with a -rc1. Adding bug fixes as someone have Consider trunk the RC. bugs.uclibc.org has quite some stuff that currently does not work and also there were reports on this very list (e.g. the glob() report) recently. We're not exactly running out of bugs yet.. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
On Tue, 2008-09-16 at 12:28 +0200, Carmelo AMOROSO wrote: Rob Landley wrote: On Tuesday 16 September 2008 01:23:37 Carmelo AMOROSO wrote: 1) How platform specific is it? Fully, TLS relocations are different from one arch to another. [SNIP] IIRC there have been some issues in the past... so, unless we are totally sure, we need to keep the working/stable and old linuxthreads.old. No, what we do is we keep the 0.9.29 tarball around and if people have bugs trying to use 0.9.30 they _report_ them to us. If they want to use the old threading code, they can use the old version of the library. If they want the new features, then they help us find (and fix) the new bugs. It may be a solution... I' don't have the power to drop linuxthrad.old anyway... we need a wider agreement (Mike, Jocke, Bernhard, Bernd..others ?) Dropping linuxthread.old is fine with me. There isn't enough developers around to maintain 3 versions, not to mention the confusion 3 versions will arise. I do think the new linuxthread need to be maintained for some time. Jocke ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
Will Newton wrote: On Tue, Sep 16, 2008 at 7:23 AM, Carmelo AMOROSO [EMAIL PROTECTED] wrote: 1) How platform specific is it? Fully, TLS relocations are different from one arch to another. 2) Does it actually have anything to do with nptl? Nothing, just dynamic linker, and obviously your compiler has to recognize the __thread keyword. I was under the impression that TLS support was a requirement of implementing NPTL, is that not the case? http://www.linux-mips.org/wiki/NPTL but it can live without nptl. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
Bernhard Reutner-Fischer wrote: On Tue, Sep 16, 2008 at 12:28:19PM +0200, Carmelo AMOROSO wrote: Well, we could ship now with a -rc1. Adding bug fixes as someone have Consider trunk the RC. bugs.uclibc.org has quite some stuff that currently does not work and also there were reports on this very list (e.g. the glob() report) recently. Ok, let's discard the -rc release, would you like to see al bugs fixed before .30 release will get shipped? We're not exactly running out of bugs yet.. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
On Tue, Sep 16, 2008 at 01:03:15PM +0200, Joakim Tjernlund wrote: On Tue, 2008-09-16 at 12:28 +0200, Carmelo AMOROSO wrote: Rob Landley wrote: On Tuesday 16 September 2008 01:23:37 Carmelo AMOROSO wrote: 1) How platform specific is it? Fully, TLS relocations are different from one arch to another. [SNIP] IIRC there have been some issues in the past... so, unless we are totally sure, we need to keep the working/stable and old linuxthreads.old. No, what we do is we keep the 0.9.29 tarball around and if people have bugs trying to use 0.9.30 they _report_ them to us. If they want to use the old threading code, they can use the old version of the library. If they want the new features, then they help us find (and fix) the new bugs. It may be a solution... I' don't have the power to drop linuxthrad.old anyway... we need a wider agreement (Mike, Jocke, Bernhard, Bernd..others ?) Dropping linuxthread.old is fine with me. There isn't enough developers around to maintain 3 versions, not to mention the confusion 3 versions linuxthreads.old doesn't really receive much manpower, AFAICS. For those that use it, it usually works for the given use-cases (from the looks). I'm curious if _anyone_ did build the new linuxthreads for arm recently? Either my checkout is somehow corrupted, or there is simply no arm support for the new linuxthreads: libpthread/linuxthreads/sysdeps/pthread/errno-loc.c:23:27: error: sysdep-cancel.h: No such file or directory make[1]: *** [libpthread/linuxthreads/sysdeps/pthread/errno-loc.oS] Error 1 $ find ./ -name sysdep-cancel.h | grep -i arm $ nada. will arise. I do think the new linuxthread need to be maintained for some time. There was a patch posted recently which brought the new linuxthreads in sync with current glibc. Perhaps you have the time to audit it? ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
On Tue, Sep 16, 2008 at 01:44:43PM +0200, Carmelo AMOROSO wrote: Bernhard Reutner-Fischer wrote: On Tue, Sep 16, 2008 at 12:28:19PM +0200, Carmelo AMOROSO wrote: Well, we could ship now with a -rc1. Adding bug fixes as someone have Consider trunk the RC. bugs.uclibc.org has quite some stuff that currently does not work and also there were reports on this very list (e.g. the glob() report) recently. Ok, let's discard the -rc release, would you like to see al bugs fixed before .30 release will get shipped? Ideally yes, but this will not happen. The fewer known/open bugs, the better, of course. I am not really aware of a real showstopper, currently. But there are of course several (almost) trivial bug reports that would be nice to address before a -final. Of course some of them may already be fixed on trunk, if so, then the reports should be closed as such. e.g.: glob() related: http://bugs.busybox.net/view.php?id=4314 http://bugs.busybox.net/view.php?id=1131 http://bugs.busybox.net/view.php?id=335 obstack gets fix-include'ed nowadays. Could need a refresh and such an update would needs testing. See also http://bugs.busybox.net/view.php?id=1864 gethostbyname() related: http://bugs.busybox.net/view.php?id=1468 http://bugs.busybox.net/view.php?id=1361 http://bugs.busybox.net/view.php?id=998 http://bugs.busybox.net/view.php?id=671 Some may be already fixed on trunk; Didn't look if my patch in the reentrant thread fixes any of the above. bugs with mmap in the subject: http://bugs.busybox.net/view.php?id=1345 http://bugs.busybox.net/view.php?id=1303 http://bugs.busybox.net/view.php?id=1071 Category stdio: http://bugs.busybox.net/view.php?id=1884 http://bugs.busybox.net/view.php?id=1453 http://bugs.busybox.net/view.php?id=1440 http://bugs.busybox.net/view.php?id=1034 http://bugs.busybox.net/view.php?id=122 Two other big spots are ldso and threads. So, if somebody can help to reproduce bugs, or verify that they are fixed on trunk, then this would be very welcome. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
On Tue, 2008-09-16 at 13:55 +0200, Bernhard Reutner-Fischer wrote: On Tue, Sep 16, 2008 at 01:03:15PM +0200, Joakim Tjernlund wrote: On Tue, 2008-09-16 at 12:28 +0200, Carmelo AMOROSO wrote: Rob Landley wrote: On Tuesday 16 September 2008 01:23:37 Carmelo AMOROSO wrote: 1) How platform specific is it? Fully, TLS relocations are different from one arch to another. [SNIP] IIRC there have been some issues in the past... so, unless we are totally sure, we need to keep the working/stable and old linuxthreads.old. No, what we do is we keep the 0.9.29 tarball around and if people have bugs trying to use 0.9.30 they _report_ them to us. If they want to use the old threading code, they can use the old version of the library. If they want the new features, then they help us find (and fix) the new bugs. It may be a solution... I' don't have the power to drop linuxthrad.old anyway... we need a wider agreement (Mike, Jocke, Bernhard, Bernd..others ?) Dropping linuxthread.old is fine with me. There isn't enough developers around to maintain 3 versions, not to mention the confusion 3 versions linuxthreads.old doesn't really receive much manpower, AFAICS. For those that use it, it usually works for the given use-cases (from the looks). I'm curious if _anyone_ did build the new linuxthreads for arm recently? Either my checkout is somehow corrupted, or there is simply no arm support for the new linuxthreads: libpthread/linuxthreads/sysdeps/pthread/errno-loc.c:23:27: error: sysdep-cancel.h: No such file or directory make[1]: *** [libpthread/linuxthreads/sysdeps/pthread/errno-loc.oS] Error 1 $ find ./ -name sysdep-cancel.h | grep -i arm $ nada. Oops, that needs to be fixed then. will arise. I do think the new linuxthread need to be maintained for some time. There was a patch posted recently which brought the new linuxthreads in sync with current glibc. Perhaps you have the time to audit it? Must have missed that one. I don't have time ATM anyway though, too many bugs to fix :( Jocke ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
Carmelo AMOROSO wrote: No, what we do is we keep the 0.9.29 tarball around and if people have bugs trying to use 0.9.30 they _report_ them to us. If they want to use the old threading code, they can use the old version of the library. If they want the new features, then they help us find (and fix) the new bugs. It may be a solution... I' don't have the power to drop linuxthrad.old anyway... we need a wider agreement (Mike, Jocke, Bernhard, Bernd..others ?) We're still using linuxthreads.old on the Blackfin. Once NPTL is in trunk, I'll have a stab at doing a Blackfin port, but for the moment I wouldn't like to see linuxthreads.old go away. We haven't tried the newer linuxthreads. It may be worth it trying to move towards it. Bernd -- This footer brought to you by insane German lawmakers. Analog Devices GmbH Wilhelm-Wagenfeld-Str. 6 80807 Muenchen Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368 Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
Rob Landley wrote: On Thursday 28 August 2008 09:25:32 Carmelo AMOROSO wrote: Looking at what we have into the nptl branch is useful. Walk trough ldso directory and look for USE_TLS to see where you should put your hands to add TLS support. Working code is a good guide. Feel free to ask for explanation whenever you want... if we can/know, we can help. Volunteers are always welcome. Has there been any follow-up on this? No that I'm aware of. I'm interested in this, because I'm trying to build Linux From Scratch 6.3 under the upcoming Firmware Linux 0.9.1, which means I'm trying to build glibc under uClibc. And current versions of glibc won't even cross compile from a host that doesn't support TLS. (Yeah, I know it's broken. It's maintained by the FSF.) I can't provide a working uClibc development environment for a target and then tell people building glibc, if you want it, is your problem if I myself can't make it work. So I need this. I note that the original paper on TLS is: http://people.redhat.com/drepper/tls.pdf Which might help... This is what I used for adding TLS/sh4 relocation support on ld.so (nptl branch) Rob Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
Bernhard Reutner-Fischer wrote: On Wed, Aug 27, 2008 at 12:58:50PM +0300, Cristi Magherusan wrote: Said that, I don't think addign TLS support for i386 is difficult, but we need someone having time to spend on it. Do you mean adding TLS support for the old linuxthreads branch on x86? Perhaps it would be better to update the non-old libpthread to something recent and add TLS to that. The .old is the proven fallback AFAIU. absolutely agreed. I can volunteer, but I may need someone more experienced to guide me. Looking at what we have into the nptl branch is useful. Walk trough ldso directory and look for USE_TLS to see where you should put your hands to add TLS support. Working code is a good guide. Feel free to ask for explanation whenever you want... if we can/know, we can help. Volunteers are always welcome. Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
Hello, On Tue, 2008-08-19 at 13:14 +0200, Carmelo AMOROSO wrote: Cristi Magherusan wrote: On Tue, 2008-08-19 at 08:34 +0200, Carmelo Amoroso wrote: Cristi Magherusan wrote: Hello, Can anyone tell which revision of the NPTL branch is tested and confirmed to work well on x86? None, only mips, arm and sh4 have nptl support. Can we hope for a x86 version in the (near) future? My application (the kvm userspace tool) needs Thread Local Storage support and some other things from the libc. It seems the main uclibc branch lacks the TLS stuff and it is present in the NPTL one. TLS does not imply NTPL. TLS concerns handling of a new kind of relocation and it should be provided by the dynamic linker, while NPTL is the Posix implementation on a pthread library rather then using linuxthreads implementation. Said that, I don't think addign TLS support for i386 is difficult, but we need someone having time to spend on it. Do you mean adding TLS support for the old linuxthreads branch on x86? I can volunteer, but I may need someone more experienced to guide me. What could be the complexity/difficulty of implementing NPTL support on x86? do you need TLS support or NPTL pthread library too? I only need TLS support. My program crashes when encountering variables declared with __thread. And that has nothing to do with the threading implementation, but only with the TLS support it provides. Regards, Cristi -- Ing. Cristi Măgherușan, Universitatea Tehnică din Cluj-Napoca Centrul de Comunicații Pusztai Kalman Tel. 0264/401247 http://cc.utcluj.ro signature.asc Description: This is a digitally signed message part ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: confirmed working NPTL revision?
On Wed, Aug 27, 2008 at 12:58:50PM +0300, Cristi Magherusan wrote: Said that, I don't think addign TLS support for i386 is difficult, but we need someone having time to spend on it. Do you mean adding TLS support for the old linuxthreads branch on x86? Perhaps it would be better to update the non-old libpthread to something recent and add TLS to that. The .old is the proven fallback AFAIU. I can volunteer, but I may need someone more experienced to guide me. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
