Doesn't install via PyPI on 64 bit system

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  pip install gmpy on 64 bit Linux
2.
3.

What is the expected output? What do you see instead?
I expected it to install fine, especially not compile for 32 bit systems, but 
for my 64 bit system.

What version of the product are you using? On what operating system?
it's a Fedora 16.

Please provide any additional information below.

$ pip install gmpy
Downloading/unpacking gmpy
  Downloading gmpy2-2.0.0b1.zip (280Kb): 280Kb downloaded
  Running setup.py egg_info for package gmpy

Installing collected packages: gmpy
  Running setup.py install for gmpy
    building 'gmpy2' extension
    gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DWITHMPFR=1 -DWITHMPC=1 -I/usr/include/python2.7 -c src/gmpy2.c -o build/temp.linux-x86_64-2.7/src/gmpy2.o
    In file included from /usr/include/features.h:387:0,
                     from /usr/include/limits.h:27,
                     from /usr/lib/gcc/x86_64-redhat-linux/4.6.3/include/limits.h:169,
                     from /usr/lib/gcc/x86_64-redhat-linux/4.6.3/include/syslimits.h:7,
                     from /usr/lib/gcc/x86_64-redhat-linux/4.6.3/include/limits.h:34,
                     from /usr/include/python2.7/Python.h:19,
                     from src/gmpy2.c:305:
    /usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or directory
    compilation terminated.
    error: command 'gcc' failed with exit status 1
    Complete output from command /tmp/week5/bin/python -c "import setuptools;__file__='/tmp/week5/build/gmpy/setup.py';exec(compile(open(__file__).read().replace('\r\n', '\n'), __file__, 'exec'))" install --single-version-externally-managed --record /tmp/pip-N82K2i-record/install-record.txt --install-headers /tmp/week5/include/site/python2.7:
    running install

running build

running build_ext

building 'gmpy2' extension

creating build

creating build/temp.linux-x86_64-2.7

creating build/temp.linux-x86_64-2.7/src

gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -march=i686 
-mtune=atom -fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG 
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m32 -march=i686 -mtune=atom 
-fasynchronous-unwind-tables -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DWITHMPFR=1 
-DWITHMPC=1 -I/usr/include/python2.7 -c src/gmpy2.c -o 
build/temp.linux-x86_64-2.7/src/gmpy2.o

In file included from /usr/include/features.h:387:0,

                 from /usr/include/limits.h:27,

                 from /usr/lib/gcc/x86_64-redhat-linux/4.6.3/include/limits.h:169,

                 from /usr/lib/gcc/x86_64-redhat-linux/4.6.3/include/syslimits.h:7,

                 from /usr/lib/gcc/x86_64-redhat-linux/4.6.3/include/limits.h:34,

                 from /usr/include/python2.7/Python.h:19,

                 from src/gmpy2.c:305:

/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file or 
directory

compilation terminated.

error: command 'gcc' failed with exit status 1

----------------------------------------
Command /tmp/week5/bin/python -c "import 
setuptools;__file__='/tmp/week5/build/gmpy/setup.py';exec(compile(open(__file__)
.read().replace('\r\n', '\n'), __file__, 'exec'))" install 
--single-version-externally-managed --record 
/tmp/pip-N82K2i-record/install-record.txt --install-headers 
/tmp/week5/include/site/python2.7 failed with error code 1

note how -m32 -march=i686 is used as arguments to gcc.

Other people seem to have this problem, too: 
https://ssl.drqueue.org/redmine/issues/149 or 
http://forums.openstack.org/viewtopic.php?f=9&t=731#p2475

I can't find out, how the default CFLAGS are built with setuptools, though. So 
I don't see "-m32" being defined by gmpy, but I also don't see where it is 
defined after all.

Original issue reported on code.google.com by 4tmue...@gmail.com on 15 Apr 2012 at 5:10

[GoogleCodeExporter]

Are you trying to install "gmpy" or "gmpy2" ? gmpy is the mature version and 
gmpy2 is the new/next version. The current version of gmpy is included in the 
Fedora Core 16 repositories.

Anyway, I tried using pip. Even though I specified "gmpy", it still downloaded 
the "gmpy2" source code. This is a bug in pip. It believes gmpy2-x.x.x is a 
later version than gmpy-x.x.x. It doesn't understand that they are different 
libraries.

If you are trying to install gmpy2, it requires later versions of GMP (5.0.x) 
and MPFR (3.1.0) than the versions included with Fedora Core 16 (4.3.2/3.0.0). 
Can you try the installation instructions at 
http://readthedocs.org/docs/gmpy2/en/latest/intro.html#installing-gmpy2-on-unix-
linux ?

I haven't figured out how to make pip pass custom build options to my setup.py 
so the above instructions are the only way I know to build gmpy2.

Original comment by casevh on 15 Apr 2012 at 6:08

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Original comment by casevh on 15 Apr 2012 at 6:08

[GoogleCodeExporter]

I entered "pip install gmpy" as "gmpy2" doesn't find any package.

Hm. Good to know about the GMP library incompatibilities. However, I doubt that 
this is the issue at hand, because it seems to me that it tries to compile for 
32 bit machines whereas I'm building on a 64bit machine.

Original comment by 4tmue...@gmail.com on 15 Apr 2012 at 6:16

[GoogleCodeExporter]

I can get gmpy2 to start building and then it fails due to missing mpfr.h file. 
But prior to that, I have the following output:

    building 'gmpy2' extension
    gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -DWITHMPFR=1 -DWITHMPC=1 -I/usr/include/python2.7 -c src/gmpy2.c -o build/temp.linux-x86_64-2.7/src/gmpy2.o

I'm on a 64-bit Fedora system. Are you sure your version of Python is a 64-bit 
version? What is the output of:

python-config --cflags

All the compiler flags should come from there. gmpy2 doesn't change any of the 
compiler flags.

Original comment by casevh on 15 Apr 2012 at 6:29

[GoogleCodeExporter]

$ python-config --cflags
-I/usr/include/python2.7 -I/usr/include/python2.7 -fno-strict-aliasing -O2 -g 
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
--param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv 
-DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE 
-fPIC -fwrapv
$

So something mangles the CFLAGS.

And I am pretty sure that I have a 64bit python, but I lack any more 
sophisticated tests than the following:
$ type -a python
python is /usr/bin/python
$ file /usr/bin/python
/usr/bin/python: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), 
dynamically linked (uses shared libs), for GNU/Linux 2.6.32, stripped
$

Original comment by 4tmue...@gmail.com on 15 Apr 2012 at 6:36

[GoogleCodeExporter]

Strange. The pip build line also includes -mtune=atom.

Is there any helpful information in ~/.pip/pip.log ?

Original comment by casevh on 15 Apr 2012 at 6:47

[GoogleCodeExporter]

nope, but it might be interesting for you to debug the versioning issue as it 
seems to scan the googlecode website. But I couldn't find anything regarding 
this compiling issue.

Original comment by 4tmue...@gmail.com on 15 Apr 2012 at 6:50

Attachments:

• pip.log

[GoogleCodeExporter]

I notice that it is calling /tmp/tmpweek5/bin/python . On my system, it calls 
/usr/bin/python.  I'm not using virtualenv so I don't know if that is causing 
the issue. After I installed the gmp 4.3.2 development package, the following 
worked to install gmpy 1.15:

sudo pip install --upgrade gmpy==1.15

At the moment, I think the only way to build gmpy2 is use python's native build 
tools as in the documentation link I included earlier. 

I'll file a bug report with pip regarding their logic for finding versions.

Original comment by casevh on 15 Apr 2012 at 7:06

[GoogleCodeExporter]

I submitted a big report for the version finding login to pip and it should be 
fixed in the next release. I've added comments to 
http://code.google.com/p/gmpy/ with comments on how to build with pip. I was 
able to build both gmpy 1.15 and gmpy2 2.0.0b1 by following those instructions 
on a 64-bit Fedora Core 16 system.

Original comment by casevh on 19 Apr 2012 at 7:37

[GoogleCodeExporter]

I had the same problem with psycopg2 and lxml and after a lot of effort tracked 
the problem down.

PYTHONPATH=/usr/lib64/python2.7 pip install <package name>

Obviously the PYTHONPATH is set to my 64 bit python installation. You will need 
to change that to point to your one.

This forces the 64bit version of all python packages to the front of pythons 
search path. 

What I found from strace() was that it looked for a match under
 /usr/lib/python2.7/<whatever>
 /usr/lib64/python2.7/<whatever>

If, like me, you have both a 32bit and 64bit version of python installed on 
your machine then the 32bit version of some files get picked up.

Specifically in this case the /usr/lib/python2.7/config/Makefile is being 
picked up. And that is setting the CFLAGS to "-mtune=atom -m32" etc

Hope that helps someone out there from having to fire up strace! ;-)
Cheers
johnoc

Original comment by joh...@gmail.com on 2 May 2012 at 4:21

[GoogleCodeExporter]

hm interestingly enough, I had the file:

$ rpm -qf /usr/lib/python2.7/config/Makefile
python-libs-2.7.2-5.2.fc16.i686
$ rpm -q --whatrequires python-libs-2.7.2-5.2.fc16.i686
no package requires python-libs-2.7.2-5.2.fc16.i686
$

I deleted that orphaned package and it looks better now.

Original comment by 4tmue...@gmail.com on 9 May 2012 at 3:03

[GoogleCodeExporter]

johnoc, thanks for your help!

4tmuelle, thanks for reporting that it's working!

Original comment by casevh on 10 May 2012 at 4:42

• Changed state: Invalid