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

[SourceForge.net]

Bugs item #1119860, was opened at 2005-02-10 08:29
Message generated for change (Comment added) made by loewis
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: 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