Summary: | sys-apps/portage-2.3.0 installs to wrong directory when cross-compiling | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Sven Müller <musv> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
install.log of portage
make.conf |
Description
Sven Müller
2016-08-22 17:31:33 UTC
Created attachment 443872 [details]
install.log of portage
install part of merging portage
Created attachment 443874 [details]
make.conf
/usr/armv7a-hardfloat-linux-gnueabi/etc/portage/make.conf
The portage ebuild uses the distutils-r1 eclass, and I believe that the lib64 part of the installation path originates from the PYTHON_SITEDIR variable which is set by the python-utils-r1 eclass. @python Am I right that python-utils-r1 eclass does not support cross-compiling? I doubt anyone of us has any clue. Cross-compilation is only supported by a few people in Gentoo, and is hard to get right. I'd say this could be PEBKAC as well -- wrong setup that results in $(get_libdir) returning lib64. In the python-utils-r1 eclass, PYTHON_SITEDIR is assigned as follows: PYTHON_SITEDIR=$("${PYTHON}" -c 'import distutils.sysconfig; print(distutils.sysconfig.get_python_lib())') || die Thhe get_libdir never enters into the picture, so the cross-compile support would have to be in distutils.sysconfig library, if anywhere. (In reply to Michał Górny from comment #4) > I'd say this could be PEBKAC > as well -- wrong setup that results in $(get_libdir) returning lib64. Thanks for this analysis. I'm not the only one: http://superuser.com/questions/1038509/why-does-portage-complain-for-lack-of-a-portage-python-module (2nd answer) This was reported months ago in bug 582194. I don't see any obvious/simple solution. *** This bug has been marked as a duplicate of bug 582194 *** |