[ python-Bugs-1119860 ] Static library incompatible with nptl
SourceForge.net
noreply at sourceforge.net
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
More information about the Python-bugs-list
mailing list