[ python-Bugs-1119860 ] Static library incompatible with nptl

Fri Feb 18 10:03:24 CET 2005

Bugs item #1119860, was opened at 2005-02-10 08:29
Message generated for change (Comment added) made by ekloef
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470

Category: Threads
Group: 3rd Party
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: daniel (ekloef)
Assigned to: Nobody/Anonymous (nobody)
Summary: Static library incompatible with nptl

Initial Comment:
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 
allocated. 

----------------------------------------------------------------------

>Comment By: daniel (ekloef)
Date: 2005-02-18 10:03

Message:
Logged In: YES 
user_id=1216071

Correct. 

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. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2005-02-18 09:54

Message:
Logged In: YES 
user_id=21627

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?

----------------------------------------------------------------------

Comment By: daniel (ekloef)
Date: 2005-02-18 09:41

Message:
Logged In: YES 
user_id=1216071

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 
version. 

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. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2005-02-18 09:32

Message:
Logged In: YES 
user_id=21627

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

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.

----------------------------------------------------------------------

Comment By: daniel (ekloef)
Date: 2005-02-18 08:13

Message:
Logged In: YES 
user_id=1216071

libpythonVERSION.a which is installed in 
lib/pythonVERSION/config/ 

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. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2005-02-17 22:27

Message:
Logged In: YES 
user_id=21627

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.

----------------------------------------------------------------------

Comment By: daniel (ekloef)
Date: 2005-02-16 09:40

Message:
Logged In: YES 
user_id=1216071

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 
problem. 

I guess it might be a stretch to call this a python bug; feel free to 
close. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1119860&group_id=5470