Bug 474882 – dev-lang/python-2.7.5 picks the wrong library directory on multilib MIPS

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Markos Chandras (RETIRED) 2013-06-26 15:25:00 UTC]

Portage 2.1.12.9 (default/linux/mips/13.0/multilib/n32, gcc-4.7.3

Timestamp of tree: Sat, 22 Jun 2013 13:45:01 +0000
ld GNU ld (GNU Binutils) 2.23.1
app-shells/bash:          4.2_p45
dev-lang/python:          2.7.5
dev-util/pkgconfig:       0.28
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.11.8
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.69
sys-devel/automake:       1.12.4, 1.13.2
sys-devel/binutils:       2.23.1
sys-devel/gcc:            4.7.3
sys-devel/gcc-config:     1.8
sys-devel/libtool:        2.4.2
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.9 (virtual/os-headers)
sys-libs/glibc:           2.17
Repositories: gentoo
ACCEPT_KEYWORDS="mips ~mips"
ACCEPT_LICENSE="* -@EULA"
CBUILD="mips64-unknown-linux-gnu"
CFLAGS="-O2"
CHOST="mips64-unknown-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="build cxx mips multilib unicode" ELIBC="glibc" KERNEL="linux" PYTHON_TARGETS="python2_7" USERLAND="GNU"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, MAKEOPTS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON


The problem is here

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
/usr/lib/gcc/mips64-unknown-linux-gnu/4.7.3/../../../../mips64-unknown-linux-gnu/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc
/usr/lib/gcc/mips64-unknown-linux-gnu/4.7.3/../../../../mips64-unknown-linux-gnu/bin/ld: /usr/lib/libc.a(ctype-info.o): ABI is incompatible with that of the selected emulation

For some reason, python does not pick the correct /lib* directory for the selected ABI. In this case it should be /usr/lib32 instead of /usr/lib

[Comment 1 Matt Turner 2013-06-26 17:17:07 UTC]

Did you say that the same version of python compiles fine under the same profile if not using catalyst?

[Comment 2 Markos Chandras (RETIRED) 2013-06-26 18:39:43 UTC]

Yes that is correct

[Comment 3 Matt Turner 2013-06-26 19:28:10 UTC]

Let's see the .spec file.

Also, maybe diff a regular build log with the build log in catalyst.

[Comment 4 Markos Chandras (RETIRED) 2013-06-27 08:15:57 UTC]

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.

[Comment 5 Markos Chandras (RETIRED) 2013-06-27 09:46:32 UTC]

=== 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

[Comment 6 Matt Turner 2013-06-27 15:50:07 UTC]

So, time to mark this as a duplicate and reopen bug 354877?

[Comment 7 Mike Gilbert 2013-06-27 16:12:40 UTC]

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.

[Comment 8 Markos Chandras (RETIRED) 2013-06-27 16:13:40 UTC]

(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.

[Comment 9 Mike Gilbert 2013-06-27 16:14:49 UTC]

(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.

[Comment 10 Mike Gilbert 2013-06-27 16:27:20 UTC]

Note to self: The bad libdirs are occuring on files under Modules, which get built by the distutils module via setup.py.

[Comment 11 Markos Chandras (RETIRED) 2013-06-27 17:13:46 UTC]

(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...

[Comment 12 Mike Gilbert 2013-06-27 17:27:01 UTC]

(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.

[Comment 13 Arfrever Frehtes Taifersar Arahesis 2013-06-27 20:56:50 UTC]

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

[Comment 14 Mike Gilbert 2013-06-28 00:02:56 UTC]

Thanks for finding that!

+  28 Jun 2013; Mike Gilbert <[e-mail]>
+  +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.

[Comment 15 Markos Chandras (RETIRED) 2013-06-28 12:40:55 UTC]

No sorry, sane problem

[Comment 16 Markos Chandras (RETIRED) 2013-06-28 12:43:18 UTC]

Sorry wrong bug :)

[Comment 17 Markos Chandras (RETIRED) 2013-06-28 13:10:32 UTC]

Yes it works fine. Thanks a lot!