| Summary: | dev-lang/python-2.7.5 picks the wrong library directory on multilib MIPS | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Markos Chandras (RETIRED) <hwoarang> |
| Component: | New packages | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | mips |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | MIPS | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Markos Chandras (RETIRED)
2013-06-26 15:25:00 UTC
Did you say that the same version of python compiles fine under the same profile if not using catalyst? Yes that is correct Let's see the .spec file. Also, maybe diff a regular build log with the build log in catalyst. I was wrong. The native system is not using a multilib profile so this is why I am not seeing the problem. This is probably a python problem with multilib profiles in general. Re-assigning to python@ For the record, adding --libdir to the python configure phase, did not fix the problem. === Python 2.7.4 === mips64-unknown-linux-gnu-gcc -fPIC -fno-strict-aliasing -O2 -fwrapv -DNDEBUG -I. -IInclude -I/var/tmp/portage/dev-lang/python-2.7.4/work/Python-2.7.4/Include -I/var/tmp/portage/dev-lang/python-2.7.4/work/mips64-unknown-linux-gnu -c /var/tmp/portage/dev-lang/python-2.7.4/work/Python-2.7.4/Modules/_struct.c -o build/temp.linux-mips64-2.7/var/tmp/portage/dev-lang/python-2.7.4/work/Python-2.7.4/Modules/_struct.o No /lib /usr/lib in here === Python 2.7.5 === mips64-unknown-linux-gnu-gcc -shared -Wl,-O1 -Wl,--as-needed -L. -Wl,-O1 -Wl,--as-needed -L. -fno-strict-aliasing -O2 -fwrapv -DNDEBUG -I. -IInclude -I/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Include build/temp.linux-mips64-2.7/var/tmp/portage/dev-lang/python-2.7.5/work/Python-2.7.5/Modules/_struct.o -L/lib -L/usr/lib -L/usr/mips64-unknown-linux-gnu/lib -L/lib32 -L/usr/lib32 -L/usr/local/lib -L. -lpython2.7 -o build/lib.linux-mips64-2.7/_struct.so So, time to mark this as a duplicate and reopen bug 354877? I'll see if I can reproduce the -L/lib -L/usr/lib thing on amd64; that at least gives me something I can troubleshoot myself. (In reply to Matt Turner from comment #6) > So, time to mark this as a duplicate and reopen bug 354877? I tried the 2.7.6 snapshot from the progress overlay. The problem does not exist there so it must be a 2.7.5 regression that was fixed upstream. I will know more once I finish the stage3 build. (In reply to Markos Chandras from comment #8) > I tried the 2.7.6 snapshot from the progress overlay. The problem does not > exist there so it must be a 2.7.5 regression that was fixed upstream. I will > know more once I finish the stage3 build. Or possibly Arfrever is applying some patch that we missed. Note to self: The bad libdirs are occuring on files under Modules, which get built by the distutils module via setup.py. (In reply to Mike Gilbert from comment #9) > (In reply to Markos Chandras from comment #8) > > I tried the 2.7.6 snapshot from the progress overlay. The problem does not > > exist there so it must be a 2.7.5 regression that was fixed upstream. I will > > know more once I finish the stage3 build. > > Or possibly Arfrever is applying some patch that we missed. but the 2.7.4 ebuild is not affected... (In reply to Markos Chandras from comment #11) > but the 2.7.4 ebuild is not affected... Right, but the problem may have been fixed by Arfrever for his 2.7.6 snapshots, rather than upstream. I'm not saying that's what happened, only that it is possible. Arfrever applieth not any relevant patches. Please test the following patch: http://bugs.python.org/issue17990 http://hg.python.org/cpython/rev/cd577c328886 http://hg.python.org/cpython/raw-rev/cd577c328886 Thanks for finding that! + 28 Jun 2013; Mike Gilbert <floppym@gentoo.org> + +files/python-2.7.5-library-path.patch, python-2.7.5.ebuild: + Fix library paths when not cross-compiling. Should resolve bug 474882. Thanks + to Arfrever for finding the upstream commit. hwoarang: Please test. No sorry, sane problem Sorry wrong bug :) Yes it works fine. Thanks a lot! |