Multilib strikes back
Hello, This is yet another pain caused by the existance of both 32 and 64-bit libraries/binaries on the same system This is the bug that landed on my plate: http://bugzilla.redhat.com/beta/show_bug.cgi?id=139911 Even though I had no plan to have both 32 and 64-bit python on the same system, the reporter of this bug is trying to compule a 32-bit version of libxml on a 64-bit system, and is getting into weird errors, mostly because the .h files have the wrong definition. Please see comment #2 from Jakub about possible solutions. If one has strong preferences one way or another please let me know and I'll write the patch, otherwise I tend to favor the (int(sizeof()) option. Thanks, Mihai
[Mihai Ibanescu]
This is yet another pain caused by the existance of both 32 and 64-bit libraries/binaries on the same system
This is the bug that landed on my plate:
http://bugzilla.redhat.com/beta/show_bug.cgi?id=139911
Even though I had no plan to have both 32 and 64-bit python on the same system, the reporter of this bug is trying to compule a 32-bit version of libxml on a 64-bit system, and is getting into weird errors, mostly because the .h files have the wrong definition.
Please see comment #2 from Jakub about possible solutions. If one has strong preferences one way or another please let me know and I'll write the patch, otherwise I tend to favor the (int(sizeof()) option.
I can't make time to pretend to understand this, but this solution won't fly: Particularly for the SIZEOF_* defines, one solution is to change them from constants to sizeof (long), sizeof (double) etc. In C that should make absolutely no difference, ... The SIZEOF_* defines are used in C preprocessor #if expressions, and sizeof() can't be used in that context. That's why Python config defines them as integer literals to begin with.
On Mon, Nov 22, 2004 at 02:04:17PM -0500, Tim Peters wrote:
[Mihai Ibanescu]
This is yet another pain caused by the existance of both 32 and 64-bit libraries/binaries on the same system
This is the bug that landed on my plate:
http://bugzilla.redhat.com/beta/show_bug.cgi?id=139911
Even though I had no plan to have both 32 and 64-bit python on the same system, the reporter of this bug is trying to compule a 32-bit version of libxml on a 64-bit system, and is getting into weird errors, mostly because the .h files have the wrong definition.
Please see comment #2 from Jakub about possible solutions. If one has strong preferences one way or another please let me know and I'll write the patch, otherwise I tend to favor the (int(sizeof()) option.
I can't make time to pretend to understand this, but this solution won't fly:
Particularly for the SIZEOF_* defines, one solution is to change them from constants to sizeof (long), sizeof (double) etc. In C that should make absolutely no difference, ...
The SIZEOF_* defines are used in C preprocessor #if expressions, and sizeof() can't be used in that context. That's why Python config defines them as integer literals to begin with.
Indeed, that would be a problem. How about a _pyconfig_32.h and a _pyconfig_64.h and have pyconfig.h include one or the other, depending on the environment? Thanks again! Misa
Mihai> How about a _pyconfig_32.h and a _pyconfig_64.h and have Mihai> pyconfig.h include one or the other, depending on the Mihai> environment? How would that be detected? As I understand the original bug report, the user gave gcc a -m32 flag. How would that be reflected in the environment? Let's assume you can coax libxml into compiling in 32-bit mode with Python support enabled even though you have a 64-bit mode Python installed. Won't that just push the problem further down the tool chain? Instead of a compilation failure wouldn't you get a runtime error of some sort, or would the two coexist? Skip
Mihai Ibanescu wrote:
Please see comment #2 from Jakub about possible solutions. If one has strong preferences one way or another please let me know and I'll write the patch, otherwise I tend to favor the (int(sizeof()) option.
I like Jakub's third proposal best: have three different pyconfig.h files, and install them into different locations. I assume that, in a multilib installation, there are per-lib directories in the include path - this is where each different pyconfig.h should go. Regards, Martin
On Mon, Nov 22, 2004 at 02:01:24PM -0600, Skip Montanaro wrote:
Mihai> How about a _pyconfig_32.h and a _pyconfig_64.h and have Mihai> pyconfig.h include one or the other, depending on the Mihai> environment?
How would that be detected? As I understand the original bug report, the user gave gcc a -m32 flag. How would that be reflected in the environment?
With the help of Jakub: pyconfig.h would have something close to:
#include
Let's assume you can coax libxml into compiling in 32-bit mode with Python support enabled even though you have a 64-bit mode Python installed. Won't that just push the problem further down the tool chain? Instead of a compilation failure wouldn't you get a runtime error of some sort, or would the two coexist?
Ideally, and that is something I would like to tackle asap, it should be possible to have both a 32-bit and a 64-bit version of python on the same machine. This is not exactly possible currently since the binaries are named the same, but that's the whole purpose of multilib :-) Misa
On Nov 22, 2004, at 9:19 PM, Mihai Ibanescu wrote:
On Mon, Nov 22, 2004 at 02:01:24PM -0600, Skip Montanaro wrote:
Mihai> How about a _pyconfig_32.h and a _pyconfig_64.h and have Mihai> pyconfig.h include one or the other, depending on the Mihai> environment?
How would that be detected? As I understand the original bug report, the user gave gcc a -m32 flag. How would that be reflected in the environment?
With the help of Jakub: pyconfig.h would have something close to:
#include
#if CHAR_BIT == 8 && LONG_MAX == 0x7fffffff #include "_pyconfig_32.h" #elif CHAR_BIT == 8 && LONG_MAX == 0x7fffffffffffffff #include "_pyconfig_64.h" #else #error Unable to detect architecture word length #endif
This way, if the compiler is in 32-bit mode, the proper file is included.
I think that is the wrong solution. The right solution is to put pyconfig.h in an arch-specific directory. In current standards, that'd probably have to be /usr/lib*: e.g. /usr/lib/python2.4/include/ and /usr/lib64/python2.4/include/. In the proposed multiarch standard (http://www.linuxbase.org/~taggart/multiarch.html), that would be /usr/include/i386-linux/ and /usr/include/x86_64-linux/. Different, but slightly related: since .py files aren't platform dependent, /usr/lib* is really the wrong place for them. They should be going in /usr/share/python2.X/ not /usr/lib*/python2.X/. Obviously the .so files still need to go in /usr/lib*, though, so that might be a bit of a trick. James
James Y Knight wrote:
On Nov 22, 2004, at 9:19 PM, Mihai Ibanescu wrote:
On Mon, Nov 22, 2004 at 02:01:24PM -0600, Skip Montanaro wrote:
Mihai> How about a _pyconfig_32.h and a _pyconfig_64.h and have Mihai> pyconfig.h include one or the other, depending on the Mihai> environment?
How would that be detected? As I understand the original bug report, the user gave gcc a -m32 flag. How would that be reflected in the environment?
With the help of Jakub: pyconfig.h would have something close to:
#include
#if CHAR_BIT == 8 && LONG_MAX == 0x7fffffff #include "_pyconfig_32.h" #elif CHAR_BIT == 8 && LONG_MAX == 0x7fffffffffffffff #include "_pyconfig_64.h" #else #error Unable to detect architecture word length #endif
This way, if the compiler is in 32-bit mode, the proper file is included.
I think that is the wrong solution. The right solution is to put pyconfig.h in an arch-specific directory.
+1 I wonder why 64-bit Unixes seem to ignore the fact that header files may very well include platform specific settings. Currently, only libs and binary files are separated according to platform. However, this is a OS builder related problem and not one that Python will need to solve.
In current standards, that'd probably have to be /usr/lib*: e.g. /usr/lib/python2.4/include/ and /usr/lib64/python2.4/include/. In the proposed multiarch standard (http://www.linuxbase.org/~taggart/multiarch.html), that would be /usr/include/i386-linux/ and /usr/include/x86_64-linux/.
Different, but slightly related: since .py files aren't platform dependent, /usr/lib* is really the wrong place for them. They should be going in /usr/share/python2.X/ not /usr/lib*/python2.X/. Obviously the .so files still need to go in /usr/lib*, though, so that might be a bit of a trick.
That won't work: extensions often place their .so files into their package directories. As a result they need a platforma specific location as well. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 26 2004)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
participants (6)
-
"Martin v. Löwis" -
James Y Knight -
M.-A. Lemburg -
Mihai Ibanescu -
Skip Montanaro -
Tim Peters