Bug 115157 - executables linked statically with /usr/lib/nptl/libpthread.a fail
executables linked statically with /usr/lib/nptl/libpthread.a fail
Product: Fedora
Classification: Fedora
Component: gcc (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
: 163083 171513 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-02-07 06:37 EST by starlight
Modified: 2009-07-14 12:59 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 12:59:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
test case (4.07 KB, application/octet-stream)
2004-02-07 06:42 EST, starlight
no flags Details

  None (edit)
Description starlight 2004-02-07 06:37:08 EST
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 

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-, and 
gcc/g++ 3.3.2 from gnu.org.  Linking against these latest 
libraries produces exact same result.
Comment 1 starlight 2004-02-07 06:42:28 EST
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
Comment 2 starlight 2004-02-07 06:46:53 EST
Forgot run instuctions:

condbench           1000  # iterations between elapsed time reports
condbench_pingpong  1000
mutexbench          1000
mutexbench_pingpong 1000
Comment 3 Jakub Jelinek 2004-10-29 05:26:10 EDT
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:
                              condbench.o (pthread_cond_wait)
                              /usr/lib64/nptl/libpthread.a(pthread_cond_wait.o) (__pthread_mutex_cond_lock)
                              /usr/lib64/nptl/libpthread.a(pthread_mutex_cond_lock.o) (__is_smp)
                              /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
Comment 4 Roland McGrath 2004-10-29 14:53:29 EDT
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.
Comment 5 Ulrich Drepper 2005-06-30 15:36:54 EDT
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.
Comment 6 Jakub Jelinek 2005-07-13 07:54:15 EDT
*** Bug 163083 has been marked as a duplicate of this bug. ***
Comment 7 Ulrich Drepper 2005-07-25 19:06:35 EDT
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.
Comment 8 David Highley 2005-09-21 06:18:53 EDT
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.
Comment 9 Gene Czarcinski 2005-10-22 14:29:55 EDT
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

Yes, for now (FC4), I can hack things to use linuxthreads but this is not a good
solution since that will disappear with FC5.
Comment 10 Jakub Jelinek 2005-10-23 03:06:47 EDT
*** Bug 171513 has been marked as a duplicate of this bug. ***
Comment 11 Jakub Jelinek 2005-10-23 03:11:50 EDT
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.
Comment 12 Bug Zapper 2008-04-03 11:31:55 EDT
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:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 13 starlight 2008-04-03 11:45:55 EDT
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.
Comment 14 Bug Zapper 2008-05-13 21:55:49 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 15 geir 2009-02-03 17:50:31 EST
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)
$ 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);

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");

        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);
        ind[0] = 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);
                fprintf(stderr, "INFO: joined thread %d\n", i);
$  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)
$ 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
Comment 16 Bug Zapper 2009-06-09 17:58:00 EDT
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: 
Comment 17 Bug Zapper 2009-07-14 12:59:35 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.