From rolla.n.selbak at intel.com Mon Mar 1 23:13:32 2004 From: rolla.n.selbak at intel.com (Selbak, Rolla N) Date: Mon, 1 Mar 2004 15:13:32 -0800 Subject: PTS test pass results - (CVS pull 2-20-04) Message-ID: <0258DE86469E2641A0C1B4C734EB8851019740A1@orsmsx407.jf.intel.com> POSIX Test Suite test pass results available for [CVS pull 2-20-04, Kernel 2.6.1, libc-2004-02-01 and message queue 4.17 patch]. We are currently in the process of setting up a main test results page, but until then, the above results can be found here: http://posixtest.sourceforge.net/testpass/PTS_cvs_2-20-04/pts_kernel-2.6 .1.htm Thanks, Rolla Selbak http://posixtest.sf.net [POSIX Test Suite project] * my views are not necessarily my employer's * From adam.li at intel.com Wed Mar 3 12:23:18 2004 From: adam.li at intel.com (Li, Adam) Date: Wed, 3 Mar 2004 20:23:18 +0800 Subject: segmentation fault at pthread_exit Message-ID: Hi all, I ran a simple test case on RHEL-3.0-update1 on ia64 but got segmentation fault _sometime_. System info: ----------------- 4 x Itanium2, 1GB DDR Red Hat Enterprise Linux AS release 3 (Taroon Update 1 Beta) Linux 2.4.21-6.EL #1 SMP # gcc -v Reading specs from /usr/lib/gcc-lib/ia64-redhat-linux/3.2.3/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with- system-zlib --enable-__cxa_atexit --host=ia64-redhat-linux Thread model: posix gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-24) #/lib/libc.so.6.1 GNU C Library stable release version 2.3.2, by Roland McGrath et al. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 3.2.3 20030502 (Red Hat Linux 3.2.3-23). Compiled on a Linux 2.4.20 system on 2003-11-07. Available extensions: GNU libio by Per Bothner crypt add-on version 2.1 by Michael Glad and others linuxthreads-0.10 by Xavier Leroy The C stubs add-on version 2.1.2. BIND-8.2.3-T5B libthread_db work sponsored by Alpha Processor Inc NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk Thread-local storage support included. Report bugs using the `glibcbug' script to . Test case: ---------------------- /* test.c */ #include #include void *a_thread_func() { pthread_exit(0); return NULL; } int main() { pthread_t new_th; printf("---------------\n"); if(pthread_create(&new_th, NULL, a_thread_func, NULL) != 0) { printf("Error creating thread\n"); return -1; } //pthread_join(new_th, NULL); printf("Test PASSED\n"); return 0; } Reproduce Steps: ---------------------- 1. # gcc -o test test.c -lpthread 2. # ldd ./test libpthread.so.0 => /lib/tls/libpthread.so.0 (0x2000000000040000) libc.so.6.1 => /lib/tls/libc.so.6.1 (0x2000000000070000) /lib/ld-linux-ia64.so.2 => /lib/ld-linux-ia64.so.2 (0x2000000000000000) (the test program links to NPTL, /lib/tls/libpthread.so.0 -> libpthread-0.60.so ) 3. # for ((i=0; i<1000; i++)) ; do ./test; done > out 2>&1 4. In one run, there are 31 "segmentation fault" among 1000 runs. ........ --------------- Test PASSED --------------- Test PASSED Segmentation fault --------------- Test PASSED --------------- ............ ------------------------------------------------------------------------ ---------- When I add a pthread_join() as above, there is _no_ segmentation fault for 1000 runs. It seems when the two threads exit at the same time, the segmentation will happen. Also in my trying on ia32 on RHEL-3.0 update1, this test case also works fine. I turn to add some debug info to a libc-20040201 source and link against it, (same gcc, but with kernel linux-2.6.1-mm2) here are some output: --------------- [test] after thread_setmem() [test] HAVE_FORCED_UNWIND [test] THREAD_SETMEM, exc.exception_class [test] THREAD_SETMEM, exc.exception_cleanup [test] __buildin_expect (libgcc_s_getcfa) [test] before libc_dlopen() libgcc_s.so.1 Test PASSED Segmentation fault --------------- It seems the segmentation fault happened when libc try to load libgcc_s.so.1 (or maybe when call into it). When there is pthread_join(), the output looks like: --------------- [test] after thread_setmem() [test] HAVE_FORCED_UNWIND [test] THREAD_SETMEM, exc.exception_class [test] THREAD_SETMEM, exc.exception_cleanup [test] __buildin_expect (libgcc_s_getcfa) [test] before libc_dlopen() libgcc_s.so.1 [test] after libc_dlopen() libgcc_s.so.1 [test] before getting the func ptr [test] exit pthread_cancel_init [test] bofore libgcc_s_forceunwind() Test PASSED --------------- BTW, in many systems, e.g, RHEL-3.0-udpate1 (ia32 and ia64), RH9, when I try: # /lib/libgcc_s.so.1 I always get segmentation fault. I am not sure whether this should be normal or not. Did I miss anything? Hoping for your comments. -adam ------------------------------------------------ Message above is personal view, not my employer's. From drepper at redhat.com Thu Mar 4 01:28:42 2004 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 03 Mar 2004 17:28:42 -0800 Subject: segmentation fault at pthread_exit In-Reply-To: References: Message-ID: <4046864A.2060106@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Li, Adam wrote: > I ran a simple test case on RHEL-3.0-update1 on ia64 but got > segmentation fault _sometime_. Do not report problems in vendor glibc versions here. Always use the vendors bug report system. This is not only for RHEL3, this applies to each and every distribution. In case there is a problem the person responsible for the code on the vendors side can report the problem here *after* verifying the problem is present in the current code. This specific problem you do not have to report since it is already fixed. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFARoZK2ijCOnn/RHQRAgYOAJ9bFll+89CpA6LBkiUl5FQHPxth0gCdEwFv iSv388wZrRvKP4ZNyuRMdUs= =IMe5 -----END PGP SIGNATURE----- From panagiotis.issaris at mech.kuleuven.ac.be Thu Mar 4 19:54:40 2004 From: panagiotis.issaris at mech.kuleuven.ac.be (Panagiotis Issaris) Date: Thu, 04 Mar 2004 20:54:40 +0100 Subject: 256 threads maximum? Message-ID: <40478980.5060309@mech.kuleuven.ac.be> Hi, The following simple testprogram tries to create the number of threads given as argv[1]. When I'm using a 2.6.3 kernel with glibc 2.3.2/NPTL 0.60, the maximum number of threads this application can create is 255. With any number higher it complains about memory allocation failing. ./thrs 255 Creating 255 threads ./thrs 256 pthread_create problem: Cannot allocate memory ^^^ perror msg When using LinuxThreads 0.10 on the same system, same binary it works just fine LD_ASSUME_KERNEL=2.4.1 ./thrs 256 Creating 256 threads For LinuxThreads the maximum number of threads appears to be 1532: LD_ASSUME_KERNEL=2.4.1 ./thrs 1532 Creating 1532 threads LD_ASSUME_KERNEL=2.4.1 ./thrs 1533 Creating 1532 threads pthread_create problem: Success Other then the strange error message, LinuxThreads seems to work. What am I doing wrong? I know that NPTL can do a lot better then this, since I have been reading reports on NPTL creating thousands of threads ( I think I recall someone stating creating 300000 threads from one process). Where does the 255 limit come from? Thanks for any reply. With friendly regards, Takis #include #include #include #include #include void* foo( void*p ) { return 0; } int main( int argc, char *argv[] ) { pthread_t * p; int i, nr = atoi( argv[ 1 ] ); p = ( pthread_t* ) calloc( nr, sizeof( pthread_t ) ); if ( p == NULL ) { perror( "not enough mem for allocating thread structs in userspace" ); exit( 1 ); } printf( "Creating %d threads\n", nr ); for ( i = 0; i < nr; i++ ) if ( pthread_create( &p[ i ], 0, foo, 0 ) != 0 ) { perror( "pthread_create problem" ); exit( 1 ); } for ( i = 0; i < nr; i++ ) if ( p[ i ] != 0 ) pthread_join( p[ i ], 0 ); return 0; } With friendly regards, Takis From slamb at slamb.org Fri Mar 5 23:13:54 2004 From: slamb at slamb.org (Scott Lamb) Date: Fri, 05 Mar 2004 17:13:54 -0600 Subject: 256 threads maximum? In-Reply-To: <40478980.5060309@mech.kuleuven.ac.be> References: <40478980.5060309@mech.kuleuven.ac.be> Message-ID: <404909B2.400@slamb.org> Panagiotis Issaris wrote: > Hi, > > The following simple testprogram tries to create the number of threads > given as argv[1]. > When I'm using a 2.6.3 kernel with glibc 2.3.2/NPTL 0.60, the maximum > number of threads this application can create is 255. With any number > higher it complains about memory allocation failing. I bet you're using a 32-bit machine with an 8 MiB stack. The top bit is reserved for kernel use, IIRC, so a program can only address 2 GiB of virtual memory. 2 GiB / 8 MiB = 256. One thread already exists. If you ran a $ ulimit -s 4096 $ ./thr 511 It would succeed, I'd think. And 512 would fail. I'm not sure why LinuxThreads was able to allocate more threads. Maybe it determines the stack size in a different way? > What am I doing wrong? I know that NPTL can do a lot better then this, > since I have been reading reports on NPTL creating thousands of threads > ( I think I recall someone stating creating 300000 threads from one > process). You can do a little better by decreasing the stack space per thread, as mentioned above. But I think they must have been doing this test on a 64-bit machine. Scott From panagiotis.issaris at mech.kuleuven.ac.be Sat Mar 6 00:59:57 2004 From: panagiotis.issaris at mech.kuleuven.ac.be (Panagiotis Issaris) Date: Sat, 06 Mar 2004 01:59:57 +0100 Subject: 256 threads maximum? In-Reply-To: <404909B2.400@slamb.org> References: <40478980.5060309@mech.kuleuven.ac.be> <404909B2.400@slamb.org> Message-ID: <4049228D.1030200@mech.kuleuven.ac.be> Scott Lamb wrote: >> The following simple testprogram tries to create the number of >> threads given as argv[1]. >> When I'm using a 2.6.3 kernel with glibc 2.3.2/NPTL 0.60, the maximum >> number of threads this application can create is 255. With any number >> higher it complains about memory allocation failing. > > > I bet you're using a 32-bit machine with an 8 MiB stack. The top bit > is reserved for kernel use, IIRC, so a program can only address 2 GiB > of virtual memory. 2 GiB / 8 MiB = 256. One thread already exists. If > you ran a > > $ ulimit -s 4096 > $ ./thr 511 > > It would succeed, I'd think. And 512 would fail. Thanks!!! I validated your explanation, and it worked out just as you predicted! > I'm not sure why LinuxThreads was able to allocate more threads. Maybe > it determines the stack size in a different way? > >> What am I doing wrong? I know that NPTL can do a lot better then >> this, since I have been reading reports on NPTL creating thousands of >> threads ( I think I recall someone stating creating 300000 threads >> from one process). > > > You can do a little better by decreasing the stack space per thread, > as mentioned above. But I think they must have been doing this test on > a 64-bit machine. Yes, you are absolutely right. Or they could have used a 7158 byte stack on a 32-bit machine :-) Thanks for your explanation, With friendly regards, Takis From Tony.Reix at BULL.NET Mon Mar 8 16:58:04 2004 From: Tony.Reix at BULL.NET (Tony Reix) Date: Mon, 8 Mar 2004 17:58:04 +0100 Subject: A trace mechanism for NPTL Message-ID: <200403081658.RAA24954@isatis.frec.bull.fr> Hi Ulrich, Since it appears that several people (Java JVMs, ...) would like to have a trace mechanism for NPTL, we propose to work on such a trace mechanism to be added to the NPTL library. It will be a free software development and all code will be part of glibc/nptl and other free software tools. We have some basic ideas about the features to be provided and how it could be done, but we need your help for understanding the rules to follow and for defining the features, requirements and how to build that trace, in order to make necessary changes acceptable and widely usable. Here are the features we are thinking of: - Users of a NPTL trace: ------------------------ a) end-users who want to understand why their multi-threaded program do not do what they are expecting. (there is a bug in their code!). They only need a high-level view of what NPTL is doing (a set of NPTL events must be defined). b) end-users who have checked that their program works perfectly well in some other environment (other operating system, or other Linux POSIX thread environment, or another NPTL version) and need to understand why it behaves differently with NPTL (there is a bug in their code that appears only within special circumstancies). c) end-users who are suspecting a complex problem in NPTL and need some data for analysing the problem and discuss with people maintaining NPTL. They are interested in having more details about what NPTL internals are doing and probably which calls to the kernel were done. - NPTL trace integrated with NPTL: ---------------------------------- - Users of type a) and b) need to be able to quickly use the NPTL trace without been required to get and install patches and recompile NPTL/glibc and maybe the kernel too. - Users of type c) may have skills and time for using a more complex tool. - Very light impact to NPTL performance: ---------------------------------------- - We see 2 solutions: - NPTL trace is incorporated into NPTL library and can be switched on easily by means of some variable to be tested: if(trace) .... - If the cost of all these "if(trace)" tests appears to be too heavy, then 2 NPTL libpthread.so.0 libs could be delivered: one with no trace one with trace - In both cases, each tracing code added to NPTL source code (C and asm) will appear as: #ifdef NPTL_TRACING if(trace) .... #endif - Tracing is done in memory and a tool is in charge of saving trace data into a file. This should reduce the performance impact of NPTL tracing: the chance to alter the behaviour of a multi-threaded application would be reduced. - Events to be traced: ---------------------- - List of Events to be defined: Mutex Events Thread Event Barrier Events Spinlock Events Semaphore Events Condition Variable Events Read-Write Lock Events - Each event log should contain: date ThreadId EventId Additional Event data - Visualization of multi-threaded trace: ---------------------------------------- - A tool will enable the end-user to see what each thread has done. - If kernel events have been recorded (with ltt) it is possible to see not only which NPTL routines have been called but also which kernel calls have been launched by NPTL. - We see 2 solutions : - Deliver a NPTL-specific trace tool delivered with NPTL. - Use a Linux standard trace tool. Like: strace, ltrace, or LTT (Linux Trace Toolkit, which collects both NPTL and kernel events info). - In order to be able to switch to one of the 2 solutions, the modification done into NPTL will be independent on the trace toolkit been used. What is your opinion about this proposal ? Amicalement/Regards, Tony Carpe Diem From crystal.xiong at intel.com Wed Mar 10 03:35:26 2004 From: crystal.xiong at intel.com (Xiong, Crystal) Date: Wed, 10 Mar 2004 11:35:26 +0800 Subject: segmentation fault at pthread_exit Message-ID: Hi drepper, Could you tell us when do you fix the problem? I have checked the glibc-2004-02-15, the problem is still existed. When I tried to build the latest glibc after (2004-03-01) on ia64 platform to test this, I got link errors. (pls refer to redhat bugzilla bug #117848). Thanks, Crystal --------------------------------------------- * This is only my personal opinion * > -----Original Message----- > From: Ulrich Drepper [mailto:drepper at redhat.com] > Sent: 2004?3?4? 9:29 > To: Li, Adam > Cc: phil-list at redhat.com; Hu, Boris; Xiong, Crystal > Subject: Re: segmentation fault at pthread_exit > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Li, Adam wrote: > > > I ran a simple test case on RHEL-3.0-update1 on ia64 but got > > segmentation fault _sometime_. > > Do not report problems in vendor glibc versions here. Always use the > vendors bug report system. This is not only for RHEL3, this applies to > each and every distribution. In case there is a problem the person > responsible for the code on the vendors side can report the problem here > *after* verifying the problem is present in the current code. > > This specific problem you do not have to report since it is already fixed. > > - -- > ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQFARoZK2ijCOnn/RHQRAgYOAJ9bFll+89CpA6LBkiUl5FQHPxth0gCdEwFv > iSv388wZrRvKP4ZNyuRMdUs= > =IMe5 > -----END PGP SIGNATURE----- From crystal.xiong at intel.com Thu Mar 11 03:28:51 2004 From: crystal.xiong at intel.com (Xiong, Crystal) Date: Thu, 11 Mar 2004 11:28:51 +0800 Subject: PTS test pass results with glibc-2004-02-15 (CVS pull 3-04-04) on IA64 platform Message-ID: POSIX Test Suite test pass results available for [CVS pull 3-04-04, Kernel 2.6.1, libc-2004-02-15 and message queue 4.17 patch on IA64 platform]. The above results can be found here: http://posixtest.sourceforge.net/testpass/PTS_cvs_3-04-04/pts_kernel-2.6.1_ia64.htm Thanks, Crystal Xiong http://posixtest.sf.net [POSIX Test Suite project] From idht4n at hotmail.com Thu Mar 11 23:01:03 2004 From: idht4n at hotmail.com (David L) Date: Thu, 11 Mar 2004 15:01:03 -0800 Subject: Thread starvation with mutex Message-ID: Sorry to beat a dead horse, but there seems to be a huge amount of confusion about NPTL and its relationship to real-time scheduling. This may not true for the experts on phil-list, but I know I'm not the only Linux user confused about this topic. There has been discussion on the linuxppc-embedded mailing list that seems to make incorrect conclusions about NPTL (see the bottom of this email for an excerpt from one such post). I can't speak for others, but here's how I came to be confused. First, I have to say, I'm far from an expert in pthreads. I've read enough to make a few simple multithreaded programs work. When I upgraded from redhat6 to redhat9, I was excited to see how the much-touted NPTL would improve the performance of my multi- threaded program. The performance sucked. It acted like it was ignoring the priorities I assigned to the threads. Was it NPTL's fault? Almost certainly not. I was probably doing something wrong that happened to work in redhat6 but not redhat9. But when I started googling to learn about NPTL, I found a several year old paper that was over my head and said real-time features were on the to-do list. Most of the rest of the stuff google turned up was arguments between experts on this list that were over my head. At one point, I concluded that SCHED_FIFO and NPTL somehow didn't play well together. I think a lot of other people have come to the same incorrect? conclusion. Somebody (Dr. Drepper maybe) should try to clear up this confusion by posting to this list and linuxppc-embedded at lists.linuxppc.org a summary of the differences between linuxthreads and NPTL with respect to "real-time" scheduling. Also, if there is a migration guide from linuxthreads to NPTL please let us know where it can be found. Thanks - David excerpt from linuxppc list: vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv >>RH9 introduces 'nptl', (locally known as 'non-portable threads >>library'), which is strictly SCHED_OTHER. Any >>RTOS code which relies on prioritized scheduling to work reliably >>(including some of the v2pthreads emulation layer) will be broken with >>'nptl'.... >> >Isn't 'nptl' also 'standard' in the new 2.6 kernel? Is it strictly >SCHED_OTHER in 2.6 also? Isn't that a severe blow to 'real-time' >embedded Linux? I don't understand... > Both statements are regrettably true. The developer(s) of 'nptl' regard regard real-time scheduling as 'nonsense' (that's what Ulrich Drepper called it!) and have no intentions of supporting it. Furthermore, their development priority is on scheduling efficiency rather than priority, and they believe it's okay to 'water down' the expectations of the applications programmer in order to boost performance. Consequently I intend to personally take a look at their code to see what can be done to make it more desirable for the real-time applications community. Drepper and crew don't see the shortcomings in their approach, so we in the real-time community will have to make any corrections ourselves. So there we have it. The new 'nptl' threading library does not support real-time scheduling. Comments? ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^6 _________________________________________________________________ Store more e-mails with MSN Hotmail Extra Storage ? 4 plans to choose from! http://click.atdmt.com/AVE/go/onm00200362ave/direct/01/ From sebastien.decugis at ext.bull.net Thu Mar 25 09:54:25 2004 From: sebastien.decugis at ext.bull.net (Sebastien Decugis) Date: Thu, 25 Mar 2004 10:54:25 +0100 Subject: small patch Message-ID: <1080208464.7135.45.camel@decugiss.frec.bull.fr> Hi I would like to discuss the nptl tst-mutex4.c and tst-rwlock4.c tests. In both cases, the test: -> creates a process shared lock located in shared memory -> takes the lock -> forks -> the child process unlocks the lock. I would like to know whether you assume that the child owns the lock or not. The only thing I could find in POSIX is in fork() description: "A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources." I don't know if "states of mutexes" means: 'the mutex is owned by me' or 'the mutex is owned by thread XXX in process YYY'. In the first case does that mean that there are two owners of the lock at the same time after the fork? In the second case, the tests are not POSIX compliant, so I submit an attached patch to make it clear in the comments. Regards -- S?bastien DECUGIS Bull S.A. -------------- next part -------------- A non-text attachment was scrubbed... Name: fix_tst_comments.patch Type: text/x-patch Size: 1398 bytes Desc: not available URL: From asheth at cisco.com Wed Mar 24 17:24:50 2004 From: asheth at cisco.com (anish sheth) Date: Wed, 24 Mar 2004 09:24:50 -0800 Subject: nptl compatibility with gcc, binutils and glibc.. Message-ID: <4.3.2.7.2.20040324092237.01ead630@mira-sjc5-4.cisco.com> hello, I am trying to use nptl with glibc 2.3.2 ( downloaded from gnu.org ). I am also using gcc-3.2.3 and binutils 2.13.2 ( both from gnu.org). when trying to compile glibc with nptl, I run into one or other errors. (glibc without nptl compiles fine with above gcc and binutils..) can you please let me know what combination of glibc, gcc, binutils and nptl is suppose to work? Please include me in your response as I am not subscribed to the alias yet. I have tried nptl versions 0.10, 0.15, 0.20, 0.25, 0.30 and 0.60 from ftp://people.redhat.com/drepper/nptl/ here are different errors: 1) nptl-0.10 make[2]: Entering directory `/aesop/asheth/src/glibc-2.3.2/csu' gcc -B/aesop/asheth/src/binutils-2.13.2-inst/bin/ ../sysdeps/unix/sysv/linux/init-first.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -g -I../include -I. -I/aesop/asheth/src/glibc-2.3.2-nptlb/csu -I.. -I../libio -I/aesop/asheth/src/glibc-2.3.2-nptlb -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../nptl/sysdeps/unix/sysv -I../nptl/sysdeps/unix -I../nptl/sysdeps/i386/i686 -I../nptl/sysdeps/i386 -I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /aesop/asheth/src/gcc-3.2.3-inst/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include -isystem /aesop/asheth/src/linux-2.4.24/include/ -D_LIBC_REENTRANT -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DHAVE_INITFINI -o /aesop/asheth/src/glibc-2.3.2-nptlb/csu/init-first.o In file included from ../sysdeps/unix/sysv/linux/ldsodefs.h:25, from ../sysdeps/unix/sysv/linux/init-first.c:30: ../sysdeps/generic/ldsodefs.h:253: warning: type defaults to `int' in declaration of `type name' ../sysdeps/generic/ldsodefs.h:253: storage class specified for parameter `type name' ../sysdeps/generic/ldsodefs.h:253: syntax error before "_dl_load_lock" ../sysdeps/generic/ldsodefs.h:256: warning: return type defaults to `int' ../sysdeps/generic/ldsodefs.h:256: warning: function declaration isn't a prototype ../sysdeps/generic/ldsodefs.h: In function `__rtld_lock_define_recursive': ../sysdeps/generic/ldsodefs.h:256: storage class specified for parameter `_dl_osversion' ../sysdeps/generic/ldsodefs.h:258: storage class specified for parameter `_dl_platform' 2) nptl-0.11 and 0.15 gcc -B/aesop/asheth/src/binutils-2.13.2-inst/bin/ ../nptl/sysdeps/unix/sysv/linux/raise.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -g -I../include -I. -I/aesop/asheth/src/glibc-2.3.2-nptlb/signal -I.. -I../libio -I/aesop/asheth/src/glibc-2.3.2-nptlb -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../nptl/sysdeps/unix/sysv -I../nptl/sysdeps/unix -I../nptl/sysdeps/i386/i686 -I../nptl/sysdeps/i386 -I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /aesop/asheth/src/gcc-3.2.3-inst/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include -isystem /aesop/asheth/src/linux-2.4.24/include/ -D_LIBC_REENTRANT -D_LIBC_REENTRANT -include ../include/libc-symbols.h -o /aesop/asheth/src/glibc-2.3.2-nptlb/signal/raise.o In file included from ../nptl/sysdeps/unix/sysv/linux/raise.c:23: ../nptl/pthreadP.h:90: warning: `visibility' attribute directive ignored ../nptl/pthreadP.h:92: warning: `visibility' attribute directive ignored ../nptl/sysdeps/unix/sysv/linux/raise.c:36:44: macro "INTERNAL_SYSCALL" requires 4 arguments, but only 2 given ../nptl/sysdeps/unix/sysv/linux/raise.c: In function `raise': ../nptl/sysdeps/unix/sysv/linux/raise.c:36: `INTERNAL_SYSCALL' undeclared (first use in this function) ../nptl/sysdeps/unix/sysv/linux/raise.c:36: (Each undeclared identifier is reported only once ../nptl/sysdeps/unix/sysv/linux/raise.c:36: for each function it appears in.) make[2]: *** [/aesop/asheth/src/glibc-2.3.2-nptlb/signal/raise.o] Error 1 make[2]: Leaving directory `/aesop/asheth/src/glibc-2.3.2/signal' make[1]: *** [signal/subdir_lib] Error 2 make[1]: Leaving directory `/aesop/asheth/src/glibc-2.3.2' make: *** [all] Error 2 3) nptl-0.20 and 0.25 gcc -B/aesop/asheth/src/binutils-2.13.2-inst/bin/ herrno.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -g -I../include -I. -I/aesop/asheth/src/glibc-2.3.2-nptlb/nptl -I.. -I../libio -I/aesop/asheth/src/glibc-2.3.2-nptlb -I../sysdeps/i386/elf -I../nptl/sysdeps/unix/sysv/linux/i386/i686 -I../nptl/sysdeps/unix/sysv/linux/i386 -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../nptl/sysdeps/unix/sysv -I../nptl/sysdeps/unix -I../nptl/sysdeps/i386/i686 -I../nptl/sysdeps/i386 -I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i686/fpu -I../sysdeps/i386/i686 -I../sysdeps/i386/i486 -I../nptl/sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /aesop/asheth/src/gcc-3.2.3-inst/bin/../lib/gcc-lib/i686-pc-linux-gnu/3.2.3/include -isystem /aesop/asheth/src/linux-2.4.24/include/ -D_LIBC_REENTRANT -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DNOT_IN_libc=1 -DIS_IN_libpthread=1 -o /aesop/asheth/src/glibc-2.3.2-nptlb/nptl/herrno.o herrno.c:27: syntax error before "int" make[2]: *** [/aesop/asheth/src/glibc-2.3.2-nptlb/nptl/herrno.o] Error 1 make[2]: Leaving directory `/aesop/asheth/src/glibc-2.3.2/nptl' make[1]: *** [nptl/others] Error 2 make[1]: Leaving directory `/aesop/asheth/src/glibc-2.3.2' make: *** [all] Error 2 4) nptl-0.30 and 0.60 configure fails with error... checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for long double... yes checking size of long double... 12 running configure fragment for ../glibc-2.3.2/sysdeps/i386/elf checking for i386 TLS support... yes running configure fragment for ../glibc-2.3.2/nptl/sysdeps/unix/sysv/linux running configure fragment for ../glibc-2.3.2/nptl/sysdeps/pthread configure: error: compiler support for __thread is required Thanks, -anish