Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 653898 - sys-devel/gcc-7.3.0-r1 cross build of non-cross gcc uses non-cross g++ for libcpp and fails - libcpp: g++: error: unrecognized command line option ‘-mfpu=neon-vfpv3’
Summary: sys-devel/gcc-7.3.0-r1 cross build of non-cross gcc uses non-cross g++ for li...
Status: RESOLVED DUPLICATE of bug 581406
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: ARM Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-04-23 15:54 UTC by Joe Harvell
Modified: 2018-10-27 21:18 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
output of sudo armv7a-pip-linux-gnueabi-emerge --info (pip-emerge-info.txt,4.72 KB, text/plain)
2018-04-23 15:54 UTC, Joe Harvell
Details
output of sudo emerge --info (emerge-info.txt,6.39 KB, text/plain)
2018-04-23 15:56 UTC, Joe Harvell
Details
build.log (build.log,290.38 KB, text/plain)
2018-04-23 16:01 UTC, Joe Harvell
Details
gcc-build-logs (gcc-build-logs.tar.bz2,61.65 KB, application/x-bzip)
2018-04-23 16:02 UTC, Joe Harvell
Details
auto-generted configure script for libcpp (libcpp-configure,242.50 KB, text/plain)
2018-04-23 18:01 UTC, Joe Harvell
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joe Harvell 2018-04-23 15:54:45 UTC
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.
Comment 1 Joe Harvell 2018-04-23 15:56:27 UTC
Created attachment 528264 [details]
output of sudo emerge --info
Comment 2 Joe Harvell 2018-04-23 16:01:47 UTC
Created attachment 528268 [details]
build.log

/usr/armv7a-pip-linux-gnueabi/tmp/portage/sys-devel/gcc-7.3.0-r1/temp/build.log
Comment 3 Joe Harvell 2018-04-23 16:02:17 UTC
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
Comment 4 Joe Harvell 2018-04-23 18:01:37 UTC
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
Comment 5 Joe Harvell 2018-04-26 04:03:06 UTC
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.
Comment 6 Joe Harvell 2018-04-28 19:03:07 UTC
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
Comment 7 Joe Harvell 2018-04-28 19:14:29 UTC
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$
Comment 8 Joe Harvell 2018-04-28 19:49:32 UTC
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
Comment 9 James Le Cuirot gentoo-dev 2018-06-22 10:33:26 UTC
(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.
Comment 10 James Le Cuirot gentoo-dev 2018-06-22 10:44:17 UTC
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.
Comment 11 Sergei Trofimovich (RETIRED) gentoo-dev 2018-06-23 09:14:15 UTC
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.
Comment 12 James Le Cuirot gentoo-dev 2018-06-23 13:02:23 UTC
Setting USE=-sanitize sidesteps the libtool relinking issue but I'm still trying to find the cause.
Comment 13 James Le Cuirot gentoo-dev 2018-06-23 14:04:26 UTC
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.
Comment 14 James Le Cuirot gentoo-dev 2018-06-23 22:39:24 UTC
(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.
Comment 15 Sergei Trofimovich (RETIRED) gentoo-dev 2018-10-27 21:18:16 UTC
CFLAGS/CXXFLAGS leaking should be fixed in ~arch toolchain patchset.

*** This bug has been marked as a duplicate of bug 581406 ***