POSIX primitive benchmarks fail to work (hang, trap) if statically linked using "-static -l/usr/lib/nptl -pthread" parameters. Work perfectly fine when linked with just "-pthread". Actual Component: nptl-devel-2.3.2-101.4 Before discovering 'nptl-devel' package, built NPTL glibc using glibc-2.3.3-7.src.rpm, binutils-2.14.90.0.8-4.src.rpm, and gcc/g++ 3.3.2 from gnu.org. Linking against these latest libraries produces exact same result.
Created attachment 97522 [details] test case To compile with static libraries: ln -f makefile.Linux.static makefile.Linux make -f MakeLinux To compile with shared libraries ln -f makefile.Linux.shared makefile.Linux make -f MakeLinux
Forgot run instuctions: condbench 1000 # iterations between elapsed time reports condbench_pingpong 1000 mutexbench 1000 mutexbench_pingpong 1000
First of all, avoid -static if you can, it only creates problems, both portability wise and others as well. If you really need to create statically linked binary with -lpthread linked in, then just use -Wl,--whole-archive -lpthread -Wl,--no-whole-archive instead of -pthread. Anything else has really many problems. Sample problems: 1) libgcc_eh.a (unwind-dw2.o) __register_frame_info_bases has #pragma weak pthread_cancel, tests pthread_cancel != NULL and if so assumes pthread_mutex_lock and pthread_mutex_unlock are available (but they are also #pragma weak) When linking with libpthread.a, you may very well end up with pthread_create linked in but not the mutex routines In your condbench the chain of requirements is: /usr/lib64/nptl/libpthread.a(pthread_cond_wait.o) condbench.o (pthread_cond_wait) /usr/lib64/nptl/libpthread.a(pthread_mutex_cond_lock.o) /usr/lib64/nptl/libpthread.a(pthread_cond_wait.o) (__pthread_mutex_cond_lock) /usr/lib64/nptl/libpthread.a(init.o) /usr/lib64/nptl/libpthread.a(pthread_mutex_cond_lock.o) (__is_smp) /usr/lib64/nptl/libpthread.a(pthread_create.o) /usr/lib64/nptl/libpthread.a(init.o) (__reclaim_stacks) 2) /usr/include/c++/3.4.2/x86_64-redhat-linux/bits/gthr-default.h has #pragma weak for most of the pthread routines and is included from the STL headers This means that e.g. pthread_mutex_condattr_init will be not included etc.
Those are both bugs in gcc/libstdc++ and should certainly be reported upstream. But because static linking has never been recommended and these are not new problems, I would not argue for anyone giving priority to fixing them and one should expect that they will change only if some upstream maintainer of those gcc libraries really cares (or someone who cares contributes good changes). Regardless, the problems are outside of glibc's domain. If there are bugs in llibc/libpthread per se with static linking, then we should fix those.
FC4 links by default with NPTL and FC5 will not have LinuxThreads at all. So, trivial close since the problem has been optimized away once the new code is available. There will be no more LT changes.
*** Bug 163083 has been marked as a duplicate of this bug. ***
That's a problem of gcc. gcc contains gthr-default.h from libstdc++ contains lines like #pragma weak pthread_mutexattr_init which cause weak references to be generated which in turn cause the functions from the .a file *not* to be pulled in.
This is not an academic issue for us as we have a very large application that took two years of effort to construct a build process for and have just run into this seemingly silent platform change to in effect only support dynamic builds. We do not understand the thinking that went into a decision to have the thread model be different between a static and dynamic build in the case of Advanced Server 3. We just did a test on Fedora core 4 and find that even though the default threads are NPTL you are still required to use the extra link options from above. If you don't you will not find out until run time that your application will segment fault. We also have a COTS component in the middle of our application that we do not have source code to and very possibly is also built with the wrong thread model. Does RedHat presume to know all of its customer development needs. We have tanked countless development hours on this issue all ready. When we queried the GNU tool lists they indicate the platform vendors document this. After many additional tanked hours I ask where is the documentation? Like how would one discover that the wrong thread model is being used. Is our only indicator the behavior of the ps command output? From the discussion above it appears that customers have no choice in how they implement there applications unless they are in a position to change vendors.
It appears that https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=171513 may be a dup of this bug. I have not been able to resolve the problem with the work-around given above ... using the work-around, I get a dynamically linked executable which is not suitable. My application is partimage and the intent of a statically linked is so that is can be run under a minimal system (e.g., the rescuecd). For some reason, only pthread_mutex_init() seems to be unresolved since other pthread functions seem to work OK. If someone can suggest an alternate method so that the #pragma weak can be overriden, I would be interested. I would prefer something minor (like that) rather than forking the partimage code (since active development seems to have resumed). Yes, for now (FC4), I can hack things to use linuxthreads but this is not a good solution since that will disappear with FC5.
*** Bug 171513 has been marked as a duplicate of this bug. ***
FYI, Alexandre Oliva is working ATM on a binutils/GCC extension that should cure gthr.h, so that it doesn't make explicit pthread_* references in user code weak. See http://sources.redhat.com/ml/binutils/2005-10/msg00300.html http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01279.html
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
It's a surprise to see this bug resurrected. Are you guys serious? It's been *four* years. Gave up on static links long ago, though now the problem of shared library dependencies preventing executables from running on different distros and different versions of the same distro is mostly in the past. Anyway, the info you need is the attachment supplied when the bug was open in 2004. It's a complete test case. Just scroll up for it.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
FYI: I find that the problem fails on a SLES 9.2 system, but works on a SLES 9.3 system: SLES 9.2 failing: $ cat /etc/SuSE-release SUSE LINUX Enterprise Server 9 (x86_64) VERSION = 9 PATCHLEVEL = 2 $ cat test2.c #include <stdio.h> #include <stdlib.h> #include <pthread.h> void * thread_sub (void *p) { int *i; i = (int *) p; printf("Hello, world, I am thread %d\n", *i); fflush(stdout); pthread_exit(NULL); } int main(int argc, char *argv[]) { pthread_t *threads; int *ind; int err; int i; int tcount = 0; void *status; if (argc < 2) { fprintf(stderr, "ERROR: must specify number of threads\n"); exit(1); } tcount = atoi(argv[1]); fprintf(stderr, "INFO: tcount = %d\n", tcount); if (tcount <= 0) { fprintf(stderr, "ERROR: thread count must be > 0\n"); } threads = malloc(sizeof(pthread_t) * tcount); if (threads == NULL) { fprintf(stderr, "ERROR: cannot malloc threads array\n"); exit (2); } ind = malloc(sizeof(int) * tcount); if (ind == NULL) { fprintf(stderr, "ERROR: cannot malloc ind array\n"); exit (2); } for (i = 1; i < tcount; i++) { ind[i] = i; fprintf(stderr, "INFO: start thread %d\n", i); err = 0; err = pthread_create (&threads[i], NULL, thread_sub, (void *) &ind[i]); if (err) { fprintf(stderr, "ERROR: pthread_create %d, err=%d\n", i, err); exit(3+i); } } ind[0] = 0; thread_sub(&ind[0]); for (i=1; i < tcount; i++) { err = pthread_join(threads[i], &status); if (err) { fprintf(stderr, "ERROR: pthread_join %d, err=%d\n", i, err); exit(10+i); } fprintf(stderr, "INFO: joined thread %d\n", i); } exit(0); } $ gcc -static test2.c -I /usr/include/nptl -L/usr/lib64/nptl -lpthread $ ./a.out 4 Memory fault $ Here is a SLES 9.3 system working: $ cat /etc/SuSE-release SUSE LINUX Enterprise Server 9 (x86_64) VERSION = 9 PATCHLEVEL = 3 $ gcc -static test2.c -I /usr/include/nptl -L/usr/lib64/nptl -lpthread $ ./a.out 4 INFO: tcount = 4 INFO: start thread 1 INFO: start thread 2 INFO: start thread 3 Hello, world, I am thread 2 Hello, world, I am thread 1 Hello, world, I am thread 0 Hello, world, I am thread 3 $
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.