Re: [Python-Dev] weird configure (autotools) setup
Hi Jeroen On Sat, 2008-04-12 at 12:00 +0200, Jeroen Ruigrok van der Werven wrote: Why is CFLAGS in Makefile.pre.in specified as CFLAGS= $(BASECFLAGS) $(OPT) $(EXTRA_CFLAGS) whereas that will negate any CFLAGS you pass to configure? I suggest you read (and follow) this issue: http://bugs.python.org/issue1628484 Bob and I are discussing the same thing, so if you want to help us in this effort of making Python's build system more flexible and correct, you're really welcome. Regards, -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 32- and 64-bit living together
Hi all, My question is simple: is there any problem when installing/using both 32- and 64-bit Python's on the same machine? I'm more concerned about header files (those installed under /usr/include/python-2.x), because as far as I could see there's nothing similar to a #ifdef USE_64BIT or something on them. Thanks, -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 32- and 64-bit living together
On Fri, 2008-04-11 at 22:06 +0200, M.-A. Lemburg wrote: Hmm, right. I tried to modify the installation path (using --libdir in ./configure) to /usr/lib64, but some *.pyo objects still are installed under /usr/lib. AFAIK, these objects are bitness-dependent (i.e., if they were generated by a 32-bit Python, they can only be execute by a 32-bit Python - and vice-versa), right? Right. Is there any way to separate these arch-dependent files in /usr/lib and /usr/lib64 depending on their bitness? There's no need for that. Only the config/ dir which is included in the Python lib dir is dependent on the Python configuration. I'm afraid I still don't understand your point. I mean, if the *.pyo file *is* dependent on the bitness of the Python interpreter (as you confirmed in my first question), therefore when I decide to have both 32- and 64-bit Python on my system I *must* have two versions of every .pyo file: one for 32- and another for 64-bit Python. What I've missed? You should probably have a look at how RedHat or openSUSE solve these problems. Some of them have patched Python to fit their needs. You may have to do that as well. I'll sure take a look at them. Thanks! -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 32- and 64-bit living together
Hi Martin, On Fri, 2008-04-11 at 23:58 +0200, Martin v. Löwis wrote: My question is simple: It's also off-topic for python-dev, which is about the development of Python, not the development with Python. With all respect, I think you're confusing things. I'm here trying to find some solutions for Python's build system (which, AFAIK, is about the development *of* Python), which I think is bogus on some systems. I'm just trying to better understand how it works here, and maybe send some patches if I find some solution for my problems. is there any problem when installing/using both 32- and 64-bit Python's on the same machine? I'm more concerned about header files (those installed under /usr/include/python-2.x), because as far as I could see there's nothing similar to a #ifdef USE_64BIT or something on them. You can't install them both into the same prefix (obviously, as they would overwrite their binary files). I was thinking about renaming the binary files, since they're (apparently) the only things that get overwritten *and* are dependent of the bit size (32/64). The rest of the files that would be overwritten, AFAIK, is not dependent of bitness so there's no problem at all. I think this may work (actually, I did the same thing successfuly with Perl). With two installation, use the header files you got from the 32-bit install for 32-bit extensions/embedding, and the header files you got from the 64-bit install for 64-bit extensions/embedding. The only header file that will actually differ is pyconfig.h. If I correctly understand what you're saying, you're proposing installing the header files in different places, right? Since these files are the same (except for pyconfig.h, as you said), I assume that the reason for this separation is only for safety. I'll consider your proposal. Regards, -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiling Python on a biarch (PPC/PPC64)
Hi Martin, On Wed, 2008-04-09 at 23:27 +0200, Martin v. Löwis wrote: Can anyone give me a hand on this? As far as I could investigate, I must change setup.py in order to get this issue fixed, right? Wrong. I didn't read your entire message, but this is definitely wrong. setup.py isn't invoked until python itself is built, and Modules/python.c is part of python itself. If I understood correctly, you're saying that Python's building process involves only the C compiler, right? So, in order to fix this issue that I've found, I only need to modify configure.in file (and maybe Makefile.pre.in). Is that correct? Regards, -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Compiling Python on a biarch (PPC/PPC64)
Hi everybody :-) I'm running a PPC64 biarch here (i.e., a 64-bit kernel with 32-bit userspace), and trying to compile Python on it. Well, as I have a GCC compiler that generates natively 32-bit executables, everything goes well when I *don't* use any specific 64-bit flag (./configure --enable-shared make make test make install). My problem happens when I try to compile Python for PPC64 using some configure flags and environment variables, like --target and CFLAGS. To be more specific, that's what I tried: ./configure --enable-shared --target=powerpc64-unknown-linux CFLAGS='-m64' The configure runs fine. But when I do a make: [EMAIL PROTECTED] ~/work/w/Python-2.5.2 $ make gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -fPIC -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c In file included from Include/Python.h:57, from ./Modules/python.c:3: Include/pyport.h:761:2: error: #error LONG_BIT definition appears wrong for platform (bad gcc/glibc config?). make: *** [Modules/python.o] Error 1 Well, now starts the part where I try to understand things, so please correct me if I'm wrong ;-). After some investigation, I thought that the error was the (absence of) detection of the building target, so I wrote a little piece of code in configure.in which detects PPC64 in the $target variable and appends to $BASECFLAGS the string '-m64'. It seems to be more than that, though (because that approach didn't work completely)... Can anyone give me a hand on this? As far as I could investigate, I must change setup.py in order to get this issue fixed, right? Thanks in advance, -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
