This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Static library incompatible with nptl
Type: Stage:
Components: Interpreter Core Versions:
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: ekloef, loewis
Priority: normal Keywords:

Created on 2005-02-10 07:29 by ekloef, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
nptl.patch ekloef, 2005-02-10 07:29 nptl patch
Messages (8)
msg24235 - (view) Author: daniel (ekloef) Date: 2005-02-10 07:29
When compiling on a linux system, the python lock 
structure contains three variables, the lock, a mutex and a 
condition variable. On systems where linuxthreads are 
used, sizeof(pthread_cond_t) == 12, but on nptl systems 
sizeof(pthread_cond_t) == 48. Why is this a problem? 
Lets say you compile the static library on an old system. 
Then the smaller pthread_cond_t will be used. If an 
application links against this library and is run on a newer 
system, ugly things will happen: only 12 bytes (+ the rest 
of the lock structure) is allocated, but the pthread 
functions will expect it to be 48 bytes... seg. fault. 
Note that this problem only occurs when using a static 
library, compiled on a linuxthreads system, and running on 
a nptl system. 
Attached is a simple fix; a padding buffer is inserted into 
the python lock structure. This ensures enough memory is 
msg24236 - (view) Author: daniel (ekloef) Date: 2005-02-16 08:40
Logged In: YES 

Just realized that the only time this bug can be triggered is if 
the static library is compiled on one (old) system and the 
application on another (new). If both are compiled on an old 
system, the versioned functions of glibc will take care of this 
I guess it might be a stretch to call this a python bug; feel free to 
msg24237 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2005-02-17 21:27
Logged In: YES 

Can you please explain what static library you are talking
about? Python compiles into /usr/local/bin/python, which is
an executable, not a library.
msg24238 - (view) Author: daniel (ekloef) Date: 2005-02-18 07:13
Logged In: YES 

libpythonVERSION.a which is installed in 
But like I said, this bug is only triggered if the lib and the 
application linking against the lib is compiled on systems with 
different glibc-versions. 
msg24239 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2005-02-18 08:32
Logged In: YES 

I see. The patch is not acceptable - what if the next
version of the Linux C library needs again more bytes in the

The real problem is that, apparently, linuxthreads and NPTL
are not binary-compatible. So in fact, an installation with
NPTL should be considered as a different operating system,
and you cannot expect to move binaries from one operating
system to another. Instead, you have to recompile the binaries.

Notice that the problem is *not* restricted to the static
library. If the application is linked to the shared
libpython, and if you not only move the application from one
system to another, but also the shared library (e.g. because
the target system does not have a libpython), the same
problem occurs.

So this is really a bug in Linux, which fails to provide
binary compatibility across installations. Closing as
third-party bug.
msg24240 - (view) Author: daniel (ekloef) Date: 2005-02-18 08:41
Logged In: YES 

No, the problem does NOT exist with the dynamic library since 
it will reference versioned glibc-functions (i.e the dynamic 
python library will use the backward compatible functions that 
is present in glibc). 
This is why compiling and linking static library and application 
on the same system is not a problem; the resulting binary will 
run on both linuxthreads and NPTL systems, since they will use 
the versioned glibc functions. However, a static library does not 
reference versioned functions until it is linked with either a 
shared library or an application. Thus, if you compile the static 
library on a linuxthreads systems but link an application against 
it on a NPTL systems, things will break, since the static library 
expects an older version of glibc but gets linked against a new 
But yes, this is not a python bug. It jsut took some time for me 
fully understand the linking process regarding the versioned 
glibc functions. 
msg24241 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2005-02-18 08:54
Logged In: YES 

So the problem occurs only when you move the static Python
library from one system to another - not, say, if you move
an application linked with the static library.

Why would you want to move the static libpython from one
system to another?
msg24242 - (view) Author: daniel (ekloef) Date: 2005-02-18 09:03
Logged In: YES 

If you already have a number of python libraries for different 
architectures, then you don't want to further increase that 
number by having multiple libraries for one or more 
architectures. It's a pain to maintain. But you may still want to 
build the main application on different systems. 
Date User Action Args
2022-04-11 14:56:09adminsetgithub: 41559
2005-02-10 07:29:14ekloefcreate