You receive this bug because this package does not respect my system's CC ( x86_64-pc-linux-gnu-gcc - /usr/bin/x86_64-pc-linux-gnu-gcc ) and calls directly gcc -/usr/bin/gcc The possible solutions to fix this issue are: 1)Fix the buildsystem, if you can 2)inherit toolchain-funcs and use tc-export CC 3)inherit toolchain-funcs and use emake CC="$(tc-getCC)" /bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sci-libs/mpir-2.6.0/work/mpir-2.6.0/mpn -I.. -D__GMP_WITHIN_GMP -I/var/tmp/portage/sci-libs/mpir-2.6.0/work/mpir-2.6.0 -DOPERATION_`echo mod_1 | sed 's/_$//'` -march=native -O2 -g0 -pipe -c -o mod_1.lo mod_1.c
there is a lot of magic in configure.in I fear doing those toolchain calls could break cross-compiling (although I don't even know if it works with the current ebuild)
(In reply to comment #1) > there is a lot of magic in configure.in > > I fear doing those toolchain calls could break cross-compiling (although I > don't even know if it works with the current ebuild) True, configure is trying to figure out themselves if we are cross compiling. Be that as it may, exporting the correct CC variable should not make things worse (otherwise its a bug in the build system). I bumped to -r1 in ~arch so that we can test this for a while. Anyone who regularly tests cross compile in sci? Please step forward. + 19 Feb 2013; Thomas Kahle <tomka@gentoo.org> +mpir-2.6.0-r1.ebuild: + use systems CC instead of gcc (bug 457912)
