I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails with the message: "Broken toolchain: cannot link a simple C program" It get's the compile flags right, but not the linker: C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -m32 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/opt/python/ia32/include/python2.7 -c' gcc: _configtest.c gcc -pthread _configtest.o -o _configtest _configtest.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status I'm bulding it using a 32bit python build that I compiled on the same system. I tried: OPT="-m32" FOPT="-m32" python setup.py build and setarch x86_64 -B python setup.py build But with the same results. Someone worked around this by altering ccompiler.py, but I'm trying to find a cleaner solution. See:http://stackoverflow.com/questions/11265057/how-do-i-install-a-32-bit-versio... Is there a standard way of doing this? Regards, David J.
On 12.12.2013 19:58, David Jones wrote:
I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails with the message:
"Broken toolchain: cannot link a simple C program"
It get's the compile flags right, but not the linker:
C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -m32 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/opt/python/ia32/include/python2.7 -c' gcc: _configtest.c gcc -pthread _configtest.o -o _configtest _configtest.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status
I'm bulding it using a 32bit python build that I compiled on the same system.
I tried:
OPT="-m32" FOPT="-m32" python setup.py build
and
setarch x86_64 -B python setup.py build
But with the same results.
Someone worked around this by altering ccompiler.py, but I'm trying to find a cleaner solution.
See:http://stackoverflow.com/questions/11265057/how-do-i-install-a-32-bit-versio...
Is there a standard way of doing this?
this might work: CC="gcc -m32" LDSHARED="gcc -m32" FF="gfortran -m32" linux32 python setup.py build
On 12/12/13 15:54, Julian Taylor wrote:
On 12.12.2013 19:58, David Jones wrote:
I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails with the message:
"Broken toolchain: cannot link a simple C program"
It get's the compile flags right, but not the linker:
C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -m32 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/opt/python/ia32/include/python2.7 -c' gcc: _configtest.c gcc -pthread _configtest.o -o _configtest _configtest.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status
I'm bulding it using a 32bit python build that I compiled on the same system.
I tried:
OPT="-m32" FOPT="-m32" python setup.py build
and
setarch x86_64 -B python setup.py build
But with the same results.
Someone worked around this by altering ccompiler.py, but I'm trying to find a cleaner solution.
See:http://stackoverflow.com/questions/11265057/how-do-i-install-a-32-bit-versio...
Is there a standard way of doing this?
this might work:
CC="gcc -m32" LDSHARED="gcc -m32" FF="gfortran -m32" linux32 python setup.py build
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
That didn't work. It says it can't find executable "gcc -m32". I tried changing ccompiler.py, per the stackoverflow post. I got further that time, but it fails with the message: build/temp.linux-i686-2.7/numpy/linalg/lapack_litemodule.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status build/temp.linux-i686-2.7/numpy/linalg/lapack_litemodule.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status error: Command "/usr/bin/gfortran -Wall -Wall -shared build/temp.linux-i686-2.7/numpy/linalg/lapack_litemodule.o build/temp.linux-i686-2.7/numpy/linalg/lapack_lite/python_xerbla.o -L/usr/lib/atlas -L/opt/python/ia32/lib -Lbuild/temp.linux-i686-2.7 -llapack -lptf77blas -lptcblas -latlas -lpython2.7 -lgfortran -o build/lib.linux-i686-2.7/numpy/linalg/lapack_lite.so" failed with exit status 1 What build options does numpy recognize? The docs ony mention CC, OPT, and FOPT, but don't give any details on how to use them. Can you pass something to setup.py?
On 12.12.2013 20:40, David Jones wrote:
On 12/12/13 15:54, Julian Taylor wrote:
On 12.12.2013 19:58, David Jones wrote:
I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails with the message:
"Broken toolchain: cannot link a simple C program"
...
this might work:
CC="gcc -m32" LDSHARED="gcc -m32" FF="gfortran -m32" linux32 python setup.py build
That didn't work. It says it can't find executable "gcc -m32". I tried changing ccompiler.py, per the stackoverflow post. I got further that time, but it fails with the message:
weird it works for me with libpython2.7-dev:i386 installed on amd64 Ubuntu 13.10 (multiarch is friggin great :D) But I had to add an additional LDFLAGS="-m32 -shared" CC="gcc -m32" LDSHARED="gcc -m32 -shared" LDFLAGS="-m32 -shared" linux32 python setup.py build you should be able to work around this error message by writing small wrapper scripts for the compiler: cat << EOF > gcc-32 #!/bin/sh gcc -m32 "$@" EOF ... CC=gcc-32 ....
On 12/12/13 16:35, Julian Taylor wrote:
On 12.12.2013 20:40, David Jones wrote:
On 12/12/13 15:54, Julian Taylor wrote:
On 12.12.2013 19:58, David Jones wrote:
I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails with the message:
"Broken toolchain: cannot link a simple C program"
... this might work:
CC="gcc -m32" LDSHARED="gcc -m32" FF="gfortran -m32" linux32 python setup.py build
That didn't work. It says it can't find executable "gcc -m32". I tried changing ccompiler.py, per the stackoverflow post. I got further that time, but it fails with the message:
weird it works for me with libpython2.7-dev:i386 installed on amd64 Ubuntu 13.10 (multiarch is friggin great :D) But I had to add an additional LDFLAGS="-m32 -shared"
CC="gcc -m32" LDSHARED="gcc -m32 -shared" LDFLAGS="-m32 -shared" linux32 python setup.py build
you should be able to work around this error message by writing small wrapper scripts for the compiler:
cat << EOF > gcc-32 #!/bin/sh gcc -m32 "$@" EOF ... CC=gcc-32 ....
I actually didn't expect it to work. It just seemed too simple. So, I'm surprised it worked for you. First off, are we using the same version of everything? I'm using Python 2.7.5, built with the following options: CFLAGS="-g -O2 -m32" LDFLAGS="-m32" ./configure --enable-unicode=ucs4 --enable-shared --prefix=/opt/python/ia32 --with-valgrind I'm building Numpy 1.8.0. I'll try the wrapper method. It seems that distutils isn't always passing the build options to the compiler and linker, so spoofing gcc and gfortran may work. It appears that numpy.distutils doesn't actually apply the linker flags. It never calls the link_executable function, except indirectly through it's reimplementation of the distutils config module. Moreover, the config module doesn't expose the necessary arguments of link_executable to set the build flags. I want to look more into the code to see exactly what's happening. It looks like the distutils config module and command package could use a lot of work. It makes sense to pass in all the build options as arguments to setup.py, rather than using environment variable. The compiler modules support this, but they're never getting that information from the config module. Of course, the may have been fixed in Python 3. I don't know. From what I can tell, distutils uses 3 methods to determine the build configuration: 1 - What version is of Python is being used? 32 bit or 64 bit? 2 - What's the architecture of the system? i.e. via uname -r. 3 - Environment variables. Unfortunately the behavior is inconsistent and poorly documented.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 12/12/13 16:35, Julian Taylor wrote:
On 12.12.2013 20:40, David Jones wrote:
On 12/12/13 15:54, Julian Taylor wrote:
On 12.12.2013 19:58, David Jones wrote:
I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails with the message:
"Broken toolchain: cannot link a simple C program"
... this might work:
CC="gcc -m32" LDSHARED="gcc -m32" FF="gfortran -m32" linux32 python setup.py build
That didn't work. It says it can't find executable "gcc -m32". I tried changing ccompiler.py, per the stackoverflow post. I got further that time, but it fails with the message:
weird it works for me with libpython2.7-dev:i386 installed on amd64 Ubuntu 13.10 (multiarch is friggin great :D) But I had to add an additional LDFLAGS="-m32 -shared"
CC="gcc -m32" LDSHARED="gcc -m32 -shared" LDFLAGS="-m32 -shared" linux32 python setup.py build
you should be able to work around this error message by writing small wrapper scripts for the compiler:
cat << EOF > gcc-32 #!/bin/sh gcc -m32 "$@" EOF ... CC=gcc-32 ....
No luck. Here are my results: bash~$ CC=gcc-32 LDSHARED=ld-32 LDFLAGS="-m32 -shared" linux32 python2.7 setup.py build /home/build/bin/ld-32: line 1: !/bin/sh: No such file or directory /usr/bin/ld: cannot find -lpython2.7 collect2: ld returned 1 exit status /home/build/bin/ld-32: line 1: !/bin/sh: No such file or directory /usr/bin/ld: cannot find -lpython2.7 collect2: ld returned 1 exit status error: Command "ld-32 -m32 -shared build/temp.linux-i686-2.7/numpy/core/src/dummymodule.o -L. -Lbuild/temp.linux-i686-2.7 -lm -lpython2.7 -o build/lib.linux-i686-2.7/numpy/core/_dummy.so" failed with exit status 1 This makes no sense to me. The linker is set to 32 bit. My python library path is 32 bit. I know it can find the library, or the build wouldn't have even started.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 12/12/13 16:35, Julian Taylor wrote:
On 12.12.2013 20:40, David Jones wrote:
On 12/12/13 15:54, Julian Taylor wrote:
On 12.12.2013 19:58, David Jones wrote:
I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails with the message:
"Broken toolchain: cannot link a simple C program"
... this might work:
CC="gcc -m32" LDSHARED="gcc -m32" FF="gfortran -m32" linux32 python setup.py build
That didn't work. It says it can't find executable "gcc -m32". I tried changing ccompiler.py, per the stackoverflow post. I got further that time, but it fails with the message:
So this is what ended of working:
CC=gcc-32 LDSHARED=ld-32 LDFLAGS="-m32 -shared -L$LD_LIBRARY_PATH" python2.7 setup.py build Somehow the value of LD_LIBRARY_PATH gets lost along the way. Perhaps distutils re-exports it with a different value, prior to calling the linker. I was getting a gfortran error at one point, but I guess it inherits -m32 from gcc-m32, so it doesn't have to be set explicitly. I still want to look into the code, to see what's going on in there. I may just write a custom config module, that allows me to pass in the build flags more cleanly.
weird it works for me with libpython2.7-dev:i386 installed on amd64 Ubuntu 13.10 (multiarch is friggin great :D) But I had to add an additional LDFLAGS="-m32 -shared"
CC="gcc -m32" LDSHARED="gcc -m32 -shared" LDFLAGS="-m32 -shared" linux32 python setup.py build
you should be able to work around this error message by writing small wrapper scripts for the compiler:
cat << EOF > gcc-32 #!/bin/sh gcc -m32 "$@" EOF ... CC=gcc-32 ....
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
this might work:
CC="gcc -m32" LDSHARED="gcc -m32" FF="gfortran -m32" linux32 python setup.py build
Compiler flags can't be added to CC, they should be in CFLAGS. (and ld flags go into LDFLAGS). Otherwise you are saying to use a program called "gcc -m32" (with a space in the name). On Fri, Dec 13, 2013 at 8:02 AM, David Jones <david.jones74@gmail.com> wrote:
On 12/12/13 16:35, Julian Taylor wrote:
On 12.12.2013 20:40, David Jones wrote:
On 12/12/13 15:54, Julian Taylor wrote:
On 12.12.2013 19:58, David Jones wrote:
I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails with the message:
"Broken toolchain: cannot link a simple C program"
... this might work:
CC="gcc -m32" LDSHARED="gcc -m32" FF="gfortran -m32" linux32 python setup.py build
That didn't work. It says it can't find executable "gcc -m32". I tried changing ccompiler.py, per the stackoverflow post. I got further that time, but it fails with the message:
So this is what ended of working:
CC=gcc-32 LDSHARED=ld-32 LDFLAGS="-m32 -shared -L$LD_LIBRARY_PATH" python2.7 setup.py build
Somehow the value of LD_LIBRARY_PATH gets lost along the way. Perhaps distutils re-exports it with a different value, prior to calling the linker.
I was getting a gfortran error at one point, but I guess it inherits -m32 from gcc-m32, so it doesn't have to be set explicitly.
I still want to look into the code, to see what's going on in there. I may just write a custom config module, that allows me to pass in the build flags more cleanly.
weird it works for me with libpython2.7-dev:i386 installed on amd64 Ubuntu 13.10 (multiarch is friggin great :D) But I had to add an additional LDFLAGS="-m32 -shared"
CC="gcc -m32" LDSHARED="gcc -m32 -shared" LDFLAGS="-m32 -shared" linux32 python setup.py build
you should be able to work around this error message by writing small wrapper scripts for the compiler:
cat << EOF > gcc-32 #!/bin/sh gcc -m32 "$@" EOF ... CC=gcc-32 ....
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 12/13/13 11:24, Charles G. Waldman wrote:
this might work:
CC="gcc -m32" LDSHARED="gcc -m32" FF="gfortran -m32" linux32 python setup.py build Compiler flags can't be added to CC, they should be in CFLAGS. (and ld flags go into LDFLAGS). Otherwise you are saying to use a program called "gcc -m32" (with a space in the name). I had tried that. But it seems that distutils, or numpy.distutils, doesn't honor those flags consistently. Instead, I used the gcc wrappers, as suggested below.
As I said, a cleaner, universally applicable method is definitely needed.
On Fri, Dec 13, 2013 at 8:02 AM, David Jones <david.jones74@gmail.com> wrote:
On 12/12/13 16:35, Julian Taylor wrote:
On 12.12.2013 20:40, David Jones wrote:
On 12/12/13 15:54, Julian Taylor wrote:
On 12.12.2013 19:58, David Jones wrote:
I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails with the message:
"Broken toolchain: cannot link a simple C program"
... this might work:
CC="gcc -m32" LDSHARED="gcc -m32" FF="gfortran -m32" linux32 python setup.py build
That didn't work. It says it can't find executable "gcc -m32". I tried changing ccompiler.py, per the stackoverflow post. I got further that time, but it fails with the message:
So this is what ended of working:
CC=gcc-32 LDSHARED=ld-32 LDFLAGS="-m32 -shared -L$LD_LIBRARY_PATH" python2.7 setup.py build
Somehow the value of LD_LIBRARY_PATH gets lost along the way. Perhaps distutils re-exports it with a different value, prior to calling the linker.
I was getting a gfortran error at one point, but I guess it inherits -m32 from gcc-m32, so it doesn't have to be set explicitly.
I still want to look into the code, to see what's going on in there. I may just write a custom config module, that allows me to pass in the build flags more cleanly.
weird it works for me with libpython2.7-dev:i386 installed on amd64 Ubuntu 13.10 (multiarch is friggin great :D) But I had to add an additional LDFLAGS="-m32 -shared"
CC="gcc -m32" LDSHARED="gcc -m32 -shared" LDFLAGS="-m32 -shared" linux32 python setup.py build
you should be able to work around this error message by writing small wrapper scripts for the compiler:
cat << EOF > gcc-32 #!/bin/sh gcc -m32 "$@" EOF ... CC=gcc-32 ....
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On 12/13/13 11:24, Charles G. Waldman wrote:
this might work:
CC="gcc -m32" LDSHARED="gcc -m32" FF="gfortran -m32" linux32 python setup.py build Compiler flags can't be added to CC, they should be in CFLAGS. (and ld flags go into LDFLAGS). Otherwise you are saying to use a program called "gcc -m32" (with a space in the name).
On Fri, Dec 13, 2013 at 8:02 AM, David Jones <david.jones74@gmail.com> wrote:
On 12/12/13 16:35, Julian Taylor wrote:
On 12.12.2013 20:40, David Jones wrote:
On 12/12/13 15:54, Julian Taylor wrote:
On 12.12.2013 19:58, David Jones wrote:
I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails with the message:
"Broken toolchain: cannot link a simple C program"
... this might work:
CC="gcc -m32" LDSHARED="gcc -m32" FF="gfortran -m32" linux32 python setup.py build
That didn't work. It says it can't find executable "gcc -m32". I tried changing ccompiler.py, per the stackoverflow post. I got further that time, but it fails with the message:
So this is what ended of working:
CC=gcc-32 LDSHARED=ld-32 LDFLAGS="-m32 -shared -L$LD_LIBRARY_PATH" python2.7 setup.py build
Somehow the value of LD_LIBRARY_PATH gets lost along the way. Perhaps distutils re-exports it with a different value, prior to calling the linker.
I was getting a gfortran error at one point, but I guess it inherits -m32 from gcc-m32, so it doesn't have to be set explicitly.
I still want to look into the code, to see what's going on in there. I may just write a custom config module, that allows me to pass in the build flags more cleanly.
weird it works for me with libpython2.7-dev:i386 installed on amd64 Ubuntu 13.10 (multiarch is friggin great :D) But I had to add an additional LDFLAGS="-m32 -shared"
CC="gcc -m32" LDSHARED="gcc -m32 -shared" LDFLAGS="-m32 -shared" linux32 python setup.py build
you should be able to work around this error message by writing small wrapper scripts for the compiler:
cat << EOF > gcc-32 #!/bin/sh gcc -m32 "$@" EOF ... CC=gcc-32 ....
Correction. Of course LD_LIBRARY_PATH isn't seen by the compiler. It only applies at run time. How embarrasing:) This isn't the first time I've been bitten by that. I don't mind doing that with manual builds, but what about with pip? Is there a way to avoid explicitly setting the library path every time you call pip, when using a custom python install?
On 13.12.2013 18:46, David Jones wrote:
...
Correction. Of course LD_LIBRARY_PATH isn't seen by the compiler. It only applies at run time. How embarrasing:) This isn't the first time I've been bitten by that.
I don't mind doing that with manual builds, but what about with pip? Is there a way to avoid explicitly setting the library path every time you call pip, when using a custom python install?
why are you actually doing this? the easiest way to get 32 bit binaries for any program is simply using a 32 bit chroot to build them. This is trivial to do on a debian based systems: pbuilder-dist i386 unstable create pbuilder-dist i386 unstable login # install dependencies and build as usual
On 12/13/13 13:48, Julian Taylor wrote:
On 13.12.2013 18:46, David Jones wrote:
...
Correction. Of course LD_LIBRARY_PATH isn't seen by the compiler. It only applies at run time. How embarrasing:) This isn't the first time I've been bitten by that.
I don't mind doing that with manual builds, but what about with pip? Is there a way to avoid explicitly setting the library path every time you call pip, when using a custom python install?
why are you actually doing this?
the easiest way to get 32 bit binaries for any program is simply using a 32 bit chroot to build them. This is trivial to do on a debian based systems:
pbuilder-dist i386 unstable create pbuilder-dist i386 unstable login # install dependencies and build as usual _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
I'm on Centos 6, but I imagine it's not that hard there either. I am doing all this in a chroot, but it's 64 bit. The purpose is to use python (via cython) for testing libraries built on a 64 bit CentOS system. It's much faster than running all the tests directly in C, because I can do everything interactively in ipython. However, the libraries are built 32 bit. WIth the simpler components I can just rebuild them as 64-bit, but with others that gets pretty complicated. To use a more current version of Python on CentOS I have to build it myself, and the simplest way to keep it up to date is using pip. However, pip installs everything from source. I ran into trouble installing numpy, but I imagine I'd have similar problems with other packages. I figure I can set the necessary environment variables in the virtualenv, and then pip should work. Anyways, thanks for your help.
On 12/13/13 13:48, Julian Taylor wrote:
On 13.12.2013 18:46, David Jones wrote:
...
Correction. Of course LD_LIBRARY_PATH isn't seen by the compiler. It only applies at run time. How embarrasing:) This isn't the first time I've been bitten by that.
I don't mind doing that with manual builds, but what about with pip? Is there a way to avoid explicitly setting the library path every time you call pip, when using a custom python install?
why are you actually doing this?
the easiest way to get 32 bit binaries for any program is simply using a 32 bit chroot to build them. This is trivial to do on a debian based systems:
pbuilder-dist i386 unstable create pbuilder-dist i386 unstable login # install dependencies and build as usual _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Just a follow-up. After building python with the -rpath linker flag set, I can install numpy using pip without having to specify the library path in LDFLAGS. CC=gcc-32 LDSHARED=ld-32 pip install numpy However, this doesn't work for building numpy directly. So it seems that pip is doing some clever magic here. In addition, pip perpetuates the -rpath value from python when building packages, so they have the correct run-time path to libpython.
As a follow up, here's an explanation of how to do this without pip or virtualenv. To do it with virtualenv, just place the wrapper scripts in your virtualenv's bin directory: To build python: Install python build dependencies (on Centos 6). Make sure to get the i686 packages: tk-devel, tcl-devel, libX11-devel, libXau-devel, sqlite-devel, gdbm-devel, readline-devel, zlib-devel, bzip2-devel, openssl-devel, krb5-devel, ncurses-devel, valgrind-devel, valgrind, libxcb-devel, libXft-devel, tk CFLAGS="-g -O2 -m32" LDFLAGS="-m32 -Wl,-rpath,/opt/python/ia32/ lib" ./configure --enable-unicode=ucs4 --enable-shared --prefix=/opt/python/ia32 --with-valgrind make make testall To build numpy: Install numpy dependencies: atlas-devel, lapack-devel, blas-devel, libgfortran Now you just need to use some compiler wrappers, so the "setup.py build" command will append the -m32 to flag to every call to the compilers. You need to wrap gcc and gfortran, and possibly g++ as well. Place the wrapper scripts and a link to your python executable in a directory, e.g. ~/bin. You could also use virtualenv to make this easier: cd ~/bin ln -sfn /opt/python/ia32/bin/python touch gcc g++ gfortan chmod u+x gcc g++ gfortran Now edit the wrapper scripts: #### gcc #### #!/bin/sh /usr/bin/gcc -m32 "$@" #### g++ #### #!/bin/sh /usr/bin/gcc -m32 "$@" #### gfotran #### #!/bin/sh /usr/bin/gfortan -m32 "$@" Add ~/bin to the front of your path: export PATH=$HOME/bin:$PATH Build numpy: python setup.py build On Thu, Dec 12, 2013 at 1:58 PM, David Jones <david.jones74@gmail.com>wrote:
I'm trying to compile 32-bit numpy on a 64 bit Centos 6 system, but fails with the message:
"Broken toolchain: cannot link a simple C program"
It get's the compile flags right, but not the linker:
C compiler: gcc -pthread -fno-strict-aliasing -g -O2 -m32 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC compile options: '-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core -Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath -Inumpy/core/src/npysort -Inumpy/core/include -I/opt/python/ia32/include/python2.7 -c' gcc: _configtest.c gcc -pthread _configtest.o -o _configtest _configtest.o: could not read symbols: File in wrong format collect2: ld returned 1 exit status
I'm bulding it using a 32bit python build that I compiled on the same system.
I tried:
OPT="-m32" FOPT="-m32" python setup.py build
and
setarch x86_64 -B python setup.py build
But with the same results.
Someone worked around this by altering ccompiler.py, but I'm trying to find a cleaner solution.
See:http://stackoverflow.com/questions/11265057/how-do-i- install-a-32-bit-version-of-numpy
Is there a standard way of doing this?
Regards, David J.
participants (3)
-
Charles G. Waldman -
David Jones -
Julian Taylor