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: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 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
