A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2004-November/050084.html below:

[Python-Dev] Multilib strikes back

[Python-Dev] Multilib strikes backMihai Ibanescu misa at redhat.com
Tue Nov 23 03:19:14 CET 2004
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 <limits.h>

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

> 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
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4