Summary: | dev-lang/python - LONG_BIT error cross-building from 64-bit to 32-bit | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | James Le Cuirot <chewi> |
Component: | [OLD] Development | Assignee: | Embedded Gentoo Team <embedded> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | python |
Priority: | Normal | Keywords: | PATCH |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | python-long-bit-fix.patch |
It turns out this was happening because I had set CONFIG_SITE. Normally ./configure loads /usr/share/config.site when this is unset but that isn't happening in this instance. I need to determine why. This fix may still be a good idea because setting CONFIG_SITE isn't an unreasonable thing to do in general. Aha. If CONFIG_SITE is not explicitly set, it tries PREFIX/share/config.site, or if --prefix wasn't given, it tries /usr/local/share/config.site, which usually doesn't exist. The cross-configure step is one of those rare occasions when ./configure is called in an ebuild without --prefix. Since our config.site is only used for cross-compiling, it shouldn't be needed here, but I still think it's a bad idea for ./configure to be called with CHOST set to the wrong value. This isn't the only thing that potentially break as a result so please apply the fix. should probably try and fix this in config.site itself You can avoid this in config.site by checking [ "${prefix}" == "/usr" ] but it's not ideal. I believe applying the patch is the correct and less ugly thing to do. Having said that, gcc is also affected by this (see bug #454138) but ./configure is called within its own build system. The aforementioned hack might be easier than patching in that case. This has been resolved for a while by avoiding pgen. |
Created attachment 336922 [details, diff] python-long-bit-fix.patch Trying to cross-compile dev-lang/python-3.2.3-r2 for armv7a-hardfloat-linux-gnueabi on x86_64-pc-linux-gnu results in... LONG_BIT definition appears wrong for platform (bad gcc/glibc config?) This happens at the "cross-configure" step. I believe it happens because even though ./configure is called with --{build,host}=${CBUILD}, the CHOST environment variable still retains its old value. When /usr/share/config.site (part of crossdev) gets executed, it sets values based on the wrong target and that causes the build to fail. The fix is simply to set CHOST="${CBUILD}". The attached patch is against 3.2.3-r2 or just use sed to apply it to all the ebuilds. sed 's/OPT="-O1"/CHOST="${CBUILD}" \0/g' *.ebuild This alone may not be enough to successfully cross-build Python but I am about to release a set of scripts that makes it possible.