https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67728
Bug ID: 67728 Summary: Build fails when cross-compiling with in-tree GMP Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bneumeier at gmail dot com Target Milestone: --- Created attachment 36399 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36399&action=edit Don't disable assembly when building GMP in-tree GMP has an issue when it is being cross-compiled for certain machine architectures without assembly loops: x86_64 to MIPS works fine, but x86_64 to ARM and x86_64 to Sparc32 both fail to build correctly. I've verified that the issue is triggered with GMP 5.1.3 and 6.0.0a; it may or may not apply with older versions of GMP. When GMP is being built as part of the GCC build with in-tree sources, GCC disables assembly by configuring GMP with: --host=none-${host_vendor}-${host_os} and --target=none-${host_vendor}-${host_os} This evokes the GMP issue, leading to the GCC build failing when it's being cross-compiled (for the problematic architectures) and GMP is built in-tree. The precise error I encountered was when linking ISL; the command: /bin/bash ./libtool --tag=CC --mode=link arm-cbl-linux-gnueabihf-gcc -g -O2 -static-libstdc++ -static-libgcc -o isl_test isl_test.o libisl.la /tmp/build/build-gcc-4/./gmp/libgmp.la fails with undefined references to __gmpn_invert_limb. In Makefile.def, I see a comment saying that the reason that asm optimizations are disabled for the GMP build is that it makes the bootstrap test of the compiler more rigorous, which makes sense. On the other hand, breaking the build for some machine architectures seems problematic! I don't know enough about the build machinery in GCC to try to figure out how to detect the particular problematic situation I've found and re-enable assembly only for that case. All I did was verify that removing the configure flags that disable assembly entirely from Makefile.def and then regenerating Makefile.in corrects the problem -- which it does! I don't know whether re-enabling assembly is the best solution, but it is the best one I could come up with.