Created attachment 528262 [details] output of sudo armv7a-pip-linux-gnueabi-emerge --info I am cross compiling a new gentoo system for my ARM cortex-a8 Beaglebone Black. While most packages are compiling just fine, a few are failing. In this case, I am building gcc (a normal ARM gcc, not a cross gcc) for the new gentoo system. The emerge fails with the following errors during the compile phase: g++: error: unrecognized command line option ‘-mfpu=neon-vfpv3’ g++: error: unrecognized command line option ‘-mfloat-abi=hard’ The build seems to be using the wrong compiler (the non-cross build system compiler for x86_64) for building the C++ objects in libcpp. All the C objects are built fine with those same command line options. Here is an overview of the steps I took: 1. Build cross toolchain (crossdev -t armv7a-pip-linux-gnueabi) 2. Edit /usr/armv7a-pip-linux-gnueabi/etc/portage/make.conf for the new system 3. extract portage-latest.tar.bz2 into /usr/armv7a-pip-linux-gnueabi/usr 4. update /usr/armv7a-pip-linux-gnueabi/etc/portage/make.profile symlink to point to ../../usr/portage/profiles/default/linux/arm/13.0/armv7a 5. sudo armv7a-pip-linux-gnueabi-emerge -a1v @system I have successfully installed 110 packages into the target root, with only 24 more to go before @system is built. I have actually repeated the command in step 5 with the addition of --noreplace and --keep-going a few times to compile as many packages as I can. But I am at a point where I can't go further.
Created attachment 528264 [details] output of sudo emerge --info
Created attachment 528268 [details] build.log /usr/armv7a-pip-linux-gnueabi/tmp/portage/sys-devel/gcc-7.3.0-r1/temp/build.log
Created attachment 528270 [details] gcc-build-logs /usr/armv7a-pip-linux-gnueabi/tmp/portage/sys-devel/gcc-7.3.0-r1/work/gcc-build-logs.tar.bz2
Created attachment 528320 [details] auto-generted configure script for libcpp The gcc-build-logs attachment has the config.log output for several sub-components, including libcpp. This is the actual configure script for libcpp that generated the libcpp config.log already included in the gcc-build-logs attachment
I noticed that some (but not all) of the config.log files show that the corresponding configure script was invoked with the wrong value for --host. In this scenario, I am using a cross compiler on the build machine (x86_64) to create a non-cross version of gcc to run on the ARM. So the correct values for this build are shown below: --build=x86_64-pc-linux-gnu --host=armv7a-pip-linux-gnueabi --target=armv7a-pip-linux-gnueabi Most of the config.log files (shown immediately below) use the correct options above: ./work/build/fixincludes/config.log ./work/build/gcc/config.log ./work/build/lto-plugin/config.log ./work/build/intl/config.log ./work/build/libcpp/config.log ./work/build/libiberty/config.log ./work/build/config.log ./work/build/libbacktrace/config.log ./work/build/libdecnumber/config.log But the remaining three config.log files are passing in the following parameters: --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=armv7a-pip-linux-gnueabi These config.log files with these wrong values for --host are shown below: ./work/build/build-x86_64-pc-linux-gnu/fixincludes/config.log ./work/build/build-x86_64-pc-linux-gnu/libcpp/config.log ./work/build/build-x86_64-pc-linux-gnu/libiberty/config.log The result is that the corresponding makefiles have definitions below: CC = gcc CXX = g++ CPP = gcc -E This causes the compiles to use the non-cross compiler on the host machine. But it is getting values for CFLAGS and/or CXXFLAGS from the make.conf in the cross root (ARM options). It doesn't make sense why this cross build of gcc is trying to build (at least in part) a cross gcc. What I am trying to build is a non cross gcc that is intended to run on the ARM host and produce ARM build products when run on the ARM host.
I read through the GCC INSTALL description of the configure options (gcc-7.3.0/INSTALL/configure.html) and noticed that the ebuild is not passing two options to configure that I think it should: --with-build-sysroot=/usr/armv7a-pip-linux-gnueabi --disable-bootstrap To test whether this is related to the problem in this report, I used ebuild to do a configure...then re-executed the configure with the additional options shown above, then did a compile. The result was it got past the error reported in this bug report and failed at a later point for a different reason. Actual commands I used shown below: joey@akita$ cat ~/bin/pipenv #!/bin/bash export PORTAGE_CONFIGROOT=/usr/armv7a-pip-linux-gnueabi exec $* joey@akita$ sudo ~/bin/pipenv ebuild /usr/portage/sys-devel/gcc/gcc-7.3.0-r1.ebuild clean joey@akita$ sudo ~/bin/pipenv ebuild /usr/portage/sys-devel/gcc/gcc-7.3.0-r1.ebuild configure joey@akita$ cd pip/gentoo/portage/tmp/portage/sys-devel/gcc-7.3.0-r1 joey@akita gcc-7.3.0-r1$ sudo chmod g+rx work joey@akita gcc-7.3.0-r1$ cd pip/gentoo/portage/tmp/portage/sys-devel/gcc-7.3.0-r1/work/build joey@akita build$ sudo ../gcc-7.3.0/configure --host=armv7a-pip-linux-gnueabi --target=armv7a-pip-linux-gnueabi --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/armv7a-pip-linux-gnueabi/gcc-bin/7.3.0 --includedir=/usr/lib/gcc/armv7a-pip-linux-gnueabi/7.3.0/include --datadir=/usr/share/gcc-data/armv7a-pip-linux-gnueabi/7.3.0 --mandir=/usr/share/gcc-data/armv7a-pip-linux-gnueabi/7.3.0/man --infodir=/usr/share/gcc-data/armv7a-pip-linux-gnueabi/7.3.0/info --with-gxx-include-dir=/usr/lib/gcc/armv7a-pip-linux-gnueabi/7.3.0/include/g++-v7 --with-python-dir=/share/gcc-data/armv7a-pip-linux-gnueabi/7.3.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 7.3.0-r1 p1.1 --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-altivec --disable-fixed-point --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer --disable-default-pie --enable-default-ssp --with-build-sysroot=/usr/armv7a-pip-linux-gnueabi --disable-bootstrap joey@akita build$ sudo ~/bin/pipenv ebuild /usr/portage/sys-devel/gcc/gcc-7.3.0-r1.ebuild compile
The effect of the above modification with the two extra options passed to configure is shown below: joey@akita build$ pwd /home/joey/pip/gentoo/portage/tmp/portage/sys-devel/gcc-7.3.0-r1/work/build joey@akita build$ file libcpp/*.o libcpp/charset.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/directives.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/directives-only.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/errors.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/expr.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/files.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/identifiers.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/init.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/lex.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/line-map.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/macro.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/mkdeps.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/pch.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/symtab.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped libcpp/traditional.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (SYSV), with debug_info, not stripped joey@akita build$ file build-x86_64-pc-linux-gnu/libcpp/*.o build-x86_64-pc-linux-gnu/libcpp/charset.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/directives.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/directives-only.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/errors.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/expr.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/files.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/identifiers.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/init.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/lex.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/line-map.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/macro.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/mkdeps.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/pch.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/symtab.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped build-x86_64-pc-linux-gnu/libcpp/traditional.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), with debug_info, not stripped I don't understand why there is any reason to build x86_64 code when using a cross-compiler to build a native ARM compiler. But that could be an upstream problem. FYI, the error I got in the compile phase has to do with the fact that there are a bunch of libraries in the SYSROOT that depend on libgcc_s.so.1. But since that is provided by gcc, which is not yet installed in SYSROOT the link fails: armv7a-pip-linux-gnueabi-g++ -no-pie -fno-PIE -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o cc1plus \ cp/cp-lang.o c-family/stub-objc.o cp/call.o cp/decl.o cp/expr.o cp/pt.o cp/typeck2.o cp/class.o cp/decl2.o cp/error.o cp/lex.o cp/parser.o cp/ptree.o cp/rtti.o cp/typeck.o cp/cvt.o cp/except.o cp/friend.o cp/init.o cp/method.o cp/search.o cp/semantics.o cp/tree.o cp/repo.o cp/dump.o cp/optimize.o cp/mangle.o cp/cp-objcp-common.o cp/name-lookup.o cp/cxx-pretty-print.o cp/cp-cilkplus.o cp/cp-gimplify.o cp/cp-array-notation.o cp/lambda.o cp/vtable-class-hierarchy.o cp/constexpr.o cp/cp-ubsan.o cp/constraint.o cp/logic.o attribs.o incpath.o c-family/c-common.o c-family/c-cppbuiltin.o c-family/c-dump.o c-family/c-format.o c-family/c-gimplify.o c-family/c-indentation.o c-family/c-lex.o c-family/c-omp.o c-family/c-opts.o c-family/c-pch.o c-family/c-ppoutput.o c-family/c-pragma.o c-family/c-pretty-print.o c-family/c-semantics.o c-family/c-ada-spec.o c-family/c-cilkplus.o c-family/array-notation-common.o c-family/cilk.o c-family/c-ubsan.o c-family/c-attribs.o c-family/c-warn.o arm-c.o glibc-c.o cc1plus-checksum.o libbackend.a main.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpc -lmpfr -lgmp -rdynamic -ldl -lz /usr/libexec/gcc/armv7a-pip-linux-gnueabi/ld: warning: libgcc_s.so.1, needed by /usr/armv7a-pip-linux-gnueabi/lib/libz.so.1, not found (try using -rpath or -rpath-link) /usr/armv7a-pip-linux-gnueabi/lib/libz.so.1: undefined reference to `__aeabi_idivmod@GCC_3.5' /usr/armv7a-pip-linux-gnueabi/lib/libz.so.1: undefined reference to `__aeabi_uidiv@GCC_3.5' /usr/armv7a-pip-linux-gnueabi/lib/libz.so.1: undefined reference to `__aeabi_uidivmod@GCC_3.5' /usr/armv7a-pip-linux-gnueabi/lib/libz.so.1: undefined reference to `__aeabi_ldivmod@GCC_3.5' collect2: error: ld returned 1 exit status make[2]: *** [../../gcc-7.3.0/gcc/lto/Make-lang.in:81: lto1] Error 1 The commands below show how the SYSROOT zlib canot be used until *after* gcc is installed. joey@akita build$ LANG=en_US.utf8 armv7a-pip-linux-gnueabi-readelf -a /usr/armv7a-pip-linux-gnueabi/lib/libz.so.1 | egrep 'NEEDED' 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x00000001 (NEEDED) Shared library: [ld-linux-armhf.so.3] 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] oey@akita build$ sudo find /usr/armv7a-pip-linux-gnueabi -name libgcc_s.so.1 joey@akita build$
I was able to get ebuild compile to succeed by re-running configure after and ebuild configure as described in previous comments: I re-ran configure with the same options that ebuild configure used, but I added: --with-build-sysroot=/usr/armv7a-pip-linux-gnueabi --disable-bootstrap and removed: -with-system-zlib --without-included-gettext Unfortunately, ebuild install fails as it is failing to include $SYSROOT in the -L options when relinking some of the libraries it built: libtool: install: (cd /home/joey/pip/gentoo/portage/tmp/portage/sys-devel/gcc-7.3.0-r1/work/build/armv7a-pip-linux-gnueabi/libsanitizer/asan; /bin/sh /home/joey/pip/gentoo/portage/tmp/portage/sys-devel/gcc-7.3.0-r1/work/build/armv7a-pip-linux-gnueabi/libsanitizer/libtool --tag CXX --mode=relink armv7a-pip-linux-gnueabi-c++ --sysroot=/usr/armv7a-pip-linux-gnueabi -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -fno-ipa-icf -I../../libstdc++-v3/include -I../../libstdc++-v3/include/armv7a-pip-linux-gnueabi -I../../../../gcc-7.3.0/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g -O2 -D_GNU_SOURCE -version-info 4:0:0 -lrt -ldl -lrt -lpthread -lm -o libasan.la -rpath /usr/lib asan_activation.lo asan_allocator.lo asan_debugging.lo asan_descriptions.lo asan_errors.lo asan_fake_stack.lo asan_flags.lo asan_globals.lo asan_interceptors.lo asan_linux.lo asan_mac.lo asan_malloc_linux.lo asan_malloc_mac.lo asan_malloc_win.lo asan_memory_profile.lo asan_new_delete.lo asan_poisoning.lo asan_posix.lo asan_report.lo asan_rtl.lo asan_stack.lo asan_stats.lo asan_suppressions.lo asan_thread.lo asan_win.lo asan_win_dll_thunk.lo asan_win_dynamic_runtime_thunk.lo ../sanitizer_common/libsanitizer_common.la ../lsan/libsanitizer_lsan.la ../interception/libinterception.la ../libbacktrace/libsanitizer_libbacktrace.la ../../libstdc++-v3/src/libstdc++.la -inst-prefix-dir /home/joey/pip/gentoo/portage/tmp/portage/sys-devel/gcc-7.3.0-r1/image/) libtool: relink: armv7a-pip-linux-gnueabi-c++ --sysroot=/usr/armv7a-pip-linux-gnueabi -fPIC -DPIC -shared -nostdlib /usr/armv7a-pip-linux-gnueabi/usr/lib/crti.o /usr/lib/gcc/armv7a-pip-linux-gnueabi/7.3.0/crtbeginS.o .libs/asan_activation.o .libs/asan_allocator.o .libs/asan_debugging.o .libs/asan_descriptions.o .libs/asan_errors.o .libs/asan_fake_stack.o .libs/asan_flags.o .libs/asan_globals.o .libs/asan_interceptors.o .libs/asan_linux.o .libs/asan_mac.o .libs/asan_malloc_linux.o .libs/asan_malloc_mac.o .libs/asan_malloc_win.o .libs/asan_memory_profile.o .libs/asan_new_delete.o .libs/asan_poisoning.o .libs/asan_posix.o .libs/asan_report.o .libs/asan_rtl.o .libs/asan_stack.o .libs/asan_stats.o .libs/asan_suppressions.o .libs/asan_thread.o .libs/asan_win.o .libs/asan_win_dll_thunk.o .libs/asan_win_dynamic_runtime_thunk.o -Wl,--whole-archive ../sanitizer_common/.libs/libsanitizer_common.a ../lsan/.libs/libsanitizer_lsan.a ../interception/.libs/libinterception.a ../libbacktrace/.libs/libsanitizer_libbacktrace.a -Wl,--no-whole-archive -ldl -lrt -lpthread -L/home/joey/pip/gentoo/portage/tmp/portage/sys-devel/gcc-7.3.0-r1/image//usr/lib -L//usr/lib -L/home/joey/pip/gentoo/portage/tmp/portage/sys-devel/gcc-7.3.0-r1/work/build/armv7a-pip-linux-gnueabi/libstdc++-v3/../libvtv/.libs -L/usr/lib/gcc/armv7a-pip-linux-gnueabi/7.3.0 -L/usr/lib/gcc/armv7a-pip-linux-gnueabi/7.3.0/../../../../armv7a-pip-linux-gnueabi/lib -L/usr/armv7a-pip-linux-gnueabi/lib -L/usr/armv7a-pip-linux-gnueabi/usr/lib -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/armv7a-pip-linux-gnueabi/7.3.0/crtendS.o /usr/armv7a-pip-linux-gnueabi/usr/lib/crtn.o -Wl,-soname -Wl,libasan.so.4 -o .libs/libasan.so.4.0.0 //usr/lib/libdl.so: file not recognized: File format not recognized
(In reply to Joe Harvell from comment #8) > Unfortunately, ebuild install fails as it is failing to include $SYSROOT in > the -L options when relinking some of the libraries it built: I haven't encountered your earlier issues though I use my own cross-boss project to do most of my cross-building. Unfortunately it isn't ready for public consumption right now but that's why I'm working on it. I did bump into your last issue just last night though. I've been through this process a few times but this is the first time I've come across this issue with gcc so it must be new. I'll see what I can find out.
Regarding your other failures, I wonder if your unusual choice of host triplet is to blame. For an armv7a hardfloat target, you would traditionally choose armv7a-hardfloat-linux-gnueabi. For the new (not quite official yet) 17.0 target, you should use armv7a-unknown-linux-gnueabihf and I thoroughly recommend you use this for new systems.
gcc ebuild (toolchain.eclass) leaks CXXFLAGS for build/host through and needs to be tweaked. I think CFLAGS handling was done for a case when g++ was not required for CHOST.
Setting USE=-sanitize sidesteps the libtool relinking issue but I'm still trying to find the cause.
Dug a little deeper. My failure might be slightly different. In the above output, libtool is seemingly not respecting SYSROOT because we can see -L/usr/lib in there. In my case, that does not happen and the relevant line in libtool looks correct. add_dir="-L${lt_sysroot:-${SYSROOT}}/$libdir" The build does not appear to set lt_sysroot or SYSROOT anywhere but SYSROOT should be set and exported by cross-emerge. Perhaps you will find this works on more recent Portage versions as there has been a lot of change around how SYSROOT is handled. It actually fails on libpthread.so rather than libdl.so for me and the contents of /usr/armv7a-unknown-linux-gnueabihf/usr/lib/libpthread.so reveal why: /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-littlearm) GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a ) libc.so is the same. I don't remember for sure but I recall these files respecting SYSROOT in the past so something has broken here.
(In reply to James Le Cuirot from comment #13) > It actually fails on libpthread.so rather than libdl.so for me and the > contents of /usr/armv7a-unknown-linux-gnueabihf/usr/lib/libpthread.so reveal > why: > > /* GNU ld script > Use the shared library, but some functions are only in > the static library, so try that secondarily. */ > OUTPUT_FORMAT(elf32-littlearm) > GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a ) > > libc.so is the same. I don't remember for sure but I recall these files > respecting SYSROOT in the past so something has broken here. Ignore that, turns out I remembered that wrong and these files are magically transformed for SYSROOT even in that form. I did find the real cause of my failure though. I am building into a ROOT that is different from /usr/${CHOST} and the aforementioned magic only works when the library is found under the SYSROOT that the toolchain has been told to use. I had defined CXX="${CHOST}-g++ --sysroot=${ROOT}". libtool normally strips out the --sysroot flag but it still gets through if it's part of CC/CXX. So why didn't it work? GCC doesn't use CC/CXX in this part of the build but CC/CXX_FOR_TARGET. Defining those to the same values fixed it for me.
CFLAGS/CXXFLAGS leaking should be fixed in ~arch toolchain patchset. *** This bug has been marked as a duplicate of bug 581406 ***