Since distutils seems to use something like "uname -m" to catch the current ARCH, distutils based ebuilds fail to build even with a e.g. x86 environment on amd64. The following patch does fix this problem. In addition, a var has to be added to some profiles, for x86/32bit profiles, it is SETARCH_ARCH_x86="i686".
Created attachment 198097 [details] patch for distutils.eclass to enable multilib/crosscompile support
Is this patch still needed? PYTHON() function is now used in distutils.eclass.
The changes in python.eclass seem to have done the work, from my last tests after your changes, so i think, this one is fixed.
I don't think this bug has been fixed. look for example at #301578 or #216958. there distutils tries to compile a python module with the host compiler instead of using the arch specific cross-compiler. the relevant env vars (CC, LDSHARED) don't seem to be defined. defining them solves the problem (see xcompile patch in #301578). Can someone please reopen?
This bug is only for multilib-portage, not for cross-compilation. Cross-compilation should be first implemented by upstream.
(In reply to comment #4) > I don't think this bug has been fixed. look for example at #301578 or #216958. > there distutils tries to compile a python module with the host compiler instead > of using the arch specific cross-compiler. the relevant env vars (CC, LDSHARED) > don't seem to be defined. defining them solves the problem (see xcompile patch > in #301578). > Can someone please reopen? > If the relevant env vars are not defined, this is an issue in the ebuild, not something, which the distutils eclass should handle. In addition does portage-multilib export the most relevant env vars, so this is no issue for portage-multilib users (portage-multilib might be extended to support crosscompile in general, but dont expect it in the near future).
