The numbering of syscalls is different between the multilib emulation glibc libraries and normal glibc libraries. eg: x86_64: asm/unistd.h:#define __NR_write 1 i386: asm/unistd.h:#define __NR_exit 1 This means that you can't compile a multilib application that uses syscalls and expect it to work. In fact it could be quite destructive to try and run it. Really, an /emul/usr/include or equivalent is required, that gcc will use instead of /usr/include when it is invoked with -m32. Arguably -nostdinc -I /emul/usr/include could be passed to gcc instead, but that could screw up search order. From man gcc: -I dir Add the directory dir to the list of directories to be searched for header files. Directories named by -I are searched before the standard system include directories. If the directory dir is a standard system include directory, the option is ignored to ensure that the default search order for system directories and the spe- cial treatment of system headers are not defeated . This affects at least the building of wine. It requires just this and a minor configure patch to create a working multilib build. Reproducible: Always Steps to Reproduce:
Would it be possible to have all the emul- packages built from scratch on the system they're being installed onto? This would remove the chance of this sort of incompatibility coming up, and also allow them to optimised for the host cpu. Or is there something that prevents this?
kernel-2.eclass already does this ...
