Description of problem: Installing Python packages via pip inside a virtualenv fails if the Python package uses a C extension. gcc is unable to find the headers for the Python dev package and the installation fails. Version-Release number of selected component (if applicable): - lib64python-devel-2.7.3-7.mga3 - python-pip-1.3.1-2.mga3 - python-virtualenv-1.7.1.2-4.mga3 How reproducible: Steps to Reproduce: 1. Make sure lib64-python-devel, python-pip, python-virtualenv, gcc are installed. 2. Create a virtualenv using: virtualenv --distribute $venv 3. Activate the virtualenv with: source $venv/bin/activate 4. Attempt to install fabric (which has a C extension dependency) using: pip install fabric Reproducible: Steps to Reproduce:
Created attachment 3977 [details] Output from PIP Added output from pip when trying to install the fabric Python package.
CC: (none) => makowski.mageia, nicolas.lecureuil, oliver.bgr
CC: (none) => lev
CC: (none) => cazzaniga.sandro
Assignee: bugsquad => cazzaniga.sandro
I take a look on virtualenv, can someone look at python-pip ?
Assignee: cazzaniga.sandro => bugsquad
CC: lev => (none)
I don't think it is python-pip the problem outside virtualenv all is ok , but inside vitualenv distutils don't provide correct links inside virtualenv : gcc -pthread -shared -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags build/temp.linux-x86_64-2.7/src/MD2.o -o build/lib.linux-x86_64-2.7/Crypto/Hash/_MD2.so outside virtualenv : gcc -pthread -shared -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags build/temp.linux-x86_64-2.7/src/MD2.o -L/usr/lib64 -lpython2.7 -o build/lib.linux-x86_64-2.7/Crypto/Hash/_MD2.so you see outside virtualenv we have : -L/usr/lib64 -lpython2.7 seems the same kind of bug than 9395
So it should just been a fix in linking in python3.
not really, we have the same kind of bug with Python3, but now here it is with Python2 under virtualenv, but both bugs are very close.
by the way, looking at this bug, I see that virtualenv is bundling its own copies of distribute and pip, presumably to install when it creates a virtualenv. rpm -ql python-virtualenv |grep tar.gz /usr/lib/python2.7/site-packages/virtualenv_support/distribute-0.6.24.tar.gz /usr/lib/python2.7/site-packages/virtualenv_support/pip-1.1.tar.gz and pip-1.1 have a security issue CVE-2013-1888 mga #10007 It should be better if we can avoid bundling distribute and pip
Dorian,inside the virtualenv, what return : python-config --ldflags what about trying before pip install fabric : LDFLAGS="$LDFLAGS `python-config --ldflags`" ?
For the record : inside the virtualenv, edit the file : lib/python2.7/config/Makefile and remove "-Wl,--no-undefined" from the LDFLAGS def and then no problem, you can install fabric
bug is in the python package (2 and 3), we need to change them to remove "-Wl,--no-undefined" from LDFLAGS in their respective ..../config/Makefile it should also resolve bug 9395
for Python2 and mga3, this bug should be solved with python-2.7.3-7.1.mga3 Python3 need to be fixed too
Depends on: (none) => 10761
I can verify that virtualenv (1.9.1-1.1.mga3) and C extensions work for Python 2.7.5 (2.7.5-1.1.mga3). I will test against Python 3, when I have the chance to do so.
Still having issues on Python 3 though, as reported above: 3.3.0-4.mga3
Should be solved in next update 3.3.0-4.2.mga3
Just an update, installations of C extensions on Python 3 work after removing "-Wl,--no-undefined" in CONFIG_ARGS and CONFIGURE_LDFLAGS from /usr/lib64/python3.3/config-3.3m/Makefile . Looking forward to 3.3.0-4.2.mga3 :)
CC: cazzaniga.sandro => (none)
Depends on: (none) => 10989
Fixed in the Bug 10989 update: http://advisories.mageia.org/MGASA-2013-0250.html
Status: NEW => RESOLVEDResolution: (none) => FIXED