Cannot compile cross-toolchain for armv7a

Message

Strange_Attractor · Post by **Strange_Attractor** » Sun Oct 04, 2015 3:48 pm

I am having troubles compiling a cross-toolchain for armv7a-hardfloat-linux-gnueabihf using crossdev, which fails at GCC stage 1 with the following error message:

Code: Select all

checking for suffix of object files... configure: error: in `/var/tmp/portage/cross-armv7a-hardfloat-linux-gnueabihf/gcc-5.2.0/work/build/armv7a-hardfloat-linux-gnueabihf/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Makefile:10599: recipe for target 'configure-target-libgcc' failed
make[1]: *** [configure-target-libgcc] Error 1
make[1]: Leaving directory '/var/tmp/portage/cross-armv7a-hardfloat-linux-gnueabihf/gcc-5.2.0/work/build'
Makefile:852: recipe for target 'all' failed
make: *** [all] Error 2

config.log contains the following:

Code: Select all

configure:3655: checking for suffix of object files
configure:3677: /var/tmp/portage/cross-armv7a-hardfloat-linux-gnueabihf/gcc-5.2.0/work/build/./gcc/xgcc -B/var/tmp/portage/cross-armv7a-hardfloat-linux-gnueabihf/gcc-5.2.0/work/build/./gcc/ -B/usr/armv7a-hardfloat-linux-gnueabihf/bin/ -B/usr/armv7a-hardfloat-linux-gnueabihf/lib/ -isystem /usr/armv7a-hardfloat-linux-gnueabihf/include -isystem /usr/armv7a-hardfloat-linux-gnueabihf/sys-include    -c -g -O2  conftest.c >&5
/usr/libexec/gcc/armv7a-hardfloat-linux-gnueabihf/as: error while loading shared libraries: libopcodes-2.25.so: cannot open shared object file: No such file or directory
configure:3681: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3695: error: in `/var/tmp/portage/cross-armv7a-hardfloat-linux-gnueabihf/gcc-5.2.0/work/build/armv7a-hardfloat-linux-gnueabihf/libgcc':
configure:3698: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

Apparently the linker looks in the wrong path when trying to load libopcodes-2.25.so (which is in /usr/lib/binutils/armv7a-hardfloat-linux-gnueabihf/2.25). Is this a crossdev bug?

I have tried using multiple versions of binutils, gcc and glibc but the problem persists. Any help would be appreciated.

Strange_Attractor · Post by **Strange_Attractor** » Sun Oct 04, 2015 5:25 pm

Update: I tried removing LDFLAGS from make.conf. Now crossdev still fails at GCC stage 1 with the error of not being able to compute suffix of object files. config.log however has different contents. The relevant parts:

Code: Select all

configure:3464: /var/tmp/portage/cross-armv7a-hardfloat-linux-gnueabihf/gcc-5.2.0/work/build/./gcc/xgcc -B/var/tmp/portage/cross-armv7a-hardfloat-linux-gnueabihf/gcc-5.2.0/work/build/./gcc/ -B/usr/armv7a-hardflo
at-linux-gnueabihf/bin/ -B/usr/armv7a-hardfloat-linux-gnueabihf/lib/ -isystem /usr/armv7a-hardfloat-linux-gnueabihf/include -isystem /usr/armv7a-hardfloat-linux-gnueabihf/sys-include    -o conftest -g -O2   conf
test.c  >&5
Assembler messages:
Fatal error: selected target format 'elf32-littlearm' unknown
configure:3467: $? = 1
configure:3655: checking for suffix of object files
configure:3677: /var/tmp/portage/cross-armv7a-hardfloat-linux-gnueabihf/gcc-5.2.0/work/build/./gcc/xgcc -B/var/tmp/portage/cross-armv7a-hardfloat-linux-gnueabihf/gcc-5.2.0/work/build/./gcc/ -B/usr/armv7a-hardflo
at-linux-gnueabihf/bin/ -B/usr/armv7a-hardfloat-linux-gnueabihf/lib/ -isystem /usr/armv7a-hardfloat-linux-gnueabihf/include -isystem /usr/armv7a-hardfloat-linux-gnueabihf/sys-include    -c -g -O2  conftest.c >&5
Assembler messages:
Fatal error: selected target format 'elf32-littlearm' unknown
configure:3681: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3695: error: in `/var/tmp/portage/cross-armv7a-hardfloat-linux-gnueabihf/gcc-5.2.0/work/build/armv7a-hardfloat-linux-gnueabihf/libgcc':
configure:3698: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.

Target format elf32-littlearm is apparently unknown to the assembler. I have no idea what this means.

Strange_Attractor · Post by **Strange_Attractor** » Thu Oct 08, 2015 11:47 am

Does noone have any idea? Should I file a bug report?

frostschutz · Post by **frostschutz** » Thu Oct 08, 2015 11:57 am

What works for me is armv7a-hardfloat-linux-gnueabi and armv7a-softfloat-linux-gnueabi.

Is there a gnueabihf or is that a typo on your part?

Strange_Attractor · Post by **Strange_Attractor** » Thu Oct 08, 2015 2:07 pm

I have read here on the forum that armv7a-hardfloat-linux-gnueabihf should be a valid target, so that's why I have used it. However, I have the exact same problem when I try to build a toolchain for armv7a-hardfloat-linux-gnueabi.

frostschutz · Post by **frostschutz** » Thu Oct 08, 2015 2:27 pm

emerge --info?

I'm on ~amd64 in case that matters...

Strange_Attractor · Post by **Strange_Attractor** » Thu Oct 08, 2015 2:38 pm

emerge --info output:

Code: Select all

Portage 2.2.22 (python 3.4.3-final-0, default/linux/amd64/13.0/desktop/gnome/systemd, gcc-5.2.0, glibc-2.22, 4.2.3-gentoo x86_64)
=================================================================
System uname: Linux-4.2.3-gentoo-x86_64-Intel-R-_Core-TM-_i7-5820K_CPU_@_3.30GHz-with-gentoo-2.2
KiB Mem:    16309760 total,   9382112 free
KiB Swap:    8388604 total,   8388604 free
Timestamp of repository gentoo: Wed, 07 Oct 2015 18:30:01 +0000
sh bash 4.3_p42
ld GNU ld (Gentoo 2.25.1 p1.1) 2.25.1
distcc 3.2rc1 x86_64-pc-linux-gnu [disabled]
ccache version 3.2.3 [enabled]
app-shells/bash:          4.3_p42::gentoo
dev-java/java-config:     2.2.0::gentoo
dev-lang/perl:            5.22.0::gentoo
dev-lang/python:          2.7.10::gentoo, 3.4.3::gentoo, 3.5.0-r1::gentoo
dev-util/ccache:          3.2.3::gentoo
dev-util/cmake:           3.3.2::gentoo
dev-util/pkgconfig:       0.29::gentoo
sys-apps/baselayout:      2.2::gentoo
sys-apps/openrc:          0.17::gentoo
sys-apps/sandbox:         2.9::gentoo
sys-devel/autoconf:       2.13::gentoo, 2.69-r1::gentoo
sys-devel/automake:       1.11.6-r1::gentoo, 1.13.4::gentoo, 1.14.1::gentoo, 1.15::gentoo
sys-devel/binutils:       2.25.1-r1::gentoo
sys-devel/gcc:            4.8.5::gentoo, 4.9.3::gentoo, 5.1.0::gentoo, 5.2.0::gentoo
sys-devel/gcc-config:     1.8::gentoo
sys-devel/libtool:        2.4.6-r1::gentoo
sys-devel/make:           4.1-r1::gentoo
sys-kernel/linux-headers: 4.2::gentoo (virtual/os-headers)
sys-libs/glibc:           2.22::gentoo
Repositories:

local-overlay
    location: /usr/local/portage
    masters: gentoo
    priority: -500

gentoo
    location: /usr/portage
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: 0

x11
    location: /var/lib/layman/x11
    masters: gentoo
    priority: 50

local-crossdev
    location: /usr/local/portage-crossdev
    masters: gentoo
    priority: 100

ACCEPT_KEYWORDS="amd64 ~amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -march=native -fno-stack-protector -fomit-frame-pointer -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/lib64/libreoffice/program/sofficerc /usr/share/config /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.6/ext-active/ /etc/php/cgi-php5.6/ext-active/ /etc/php/cli-php5.6/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"
CXXFLAGS="-O2 -march=native -fno-stack-protector -fomit-frame-pointer -pipe"
DISTDIR="/usr/portage/distfiles"
EMERGE_DEFAULT_OPTS="--keep-going --autounmask-keep-masks"
FCFLAGS="-O2 -march=native -fno-stack-protector -fomit-frame-pointer -pipe"
FEATURES="assume-digests binpkg-logs ccache cgroup clean-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch parallel-install preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"
FFLAGS="-O2 -march=native -fno-stack-protector -fomit-frame-pointer -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="sv_SE.utf8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--sort-common -Wl,--relax"
MAKEOPTS="-j16 -l16"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
USE="X a52 aac aacplus acl acpi alsa amd64 berkdb branding bzip2 cairo cdda cdr cli colord crypt cups cxx dbus dri dts dvd dvdr eds emboss encode evo exif fam fftw firefox flac fortran gdbm gif glamor gnome gnome-keyring gnome-online-accounts gpm gstreamer gtk iconv introspection ipv6 jpeg kdbus lcms ldap libnotify libsecret mad mmx mmxext mng modules mp3 mp4 mpeg multilib nautilus ncurses nls nptl nsplugin ogg opengl openmp pam pango pcre pdf png policykit ppds pulseaudio qt3support qt4 qt5 readline sdl seccomp session smp spell sse sse2 ssl startup-notification svg systemd tcpd threads tiff tracker truetype udev udisks unicode upower usb vaapi vdpau vorbis vpx wayland wxwidgets x264 x265 xcb xml xv xvid zlib" ABI_X86="64" ALSA_CARDS="hda-intel" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="aes avx avx2 fma3 mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-64" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en en_US sv sv_SE" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_4" QEMU_SOFTMMU_TARGETS="x86_64 arm i386" QEMU_USER_TARGETS="arm x86_64 i386" RUBY_TARGETS="ruby20 ruby21" USERLAND="GNU" VIDEO_CARDS="radeon radeonsi amdgpu" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON

HalfwayToHeaven · Post by **HalfwayToHeaven** » Mon Oct 12, 2015 7:49 pm

I ran into the same problem as described in the first post, I managed to solve it by doing:

Code: Select all

echo "/usr/lib64/binutils/armv7a-hardfloat-linux-gnueabi/2.22" >/etc/ld.so.conf.d/10armv7a.conf && env-update

And then re-running crossdev. If another version of binutils is used, 2.22 should be replaced by it. To find out where libopcodes-*.so is located:

Code: Select all

find /usr/lib64 -name "libopcodes*"

Not sure why it isn't detected, but this way it will be searched for in the correct path.

biergaizi · Post by **biergaizi** » Fri Oct 30, 2015 5:05 pm

Same problem here!

I cannot compile AVR, MIPS, or MinGW toolchains at all. It seems crossdev is no longer able to deal with path of libraries properly! Regardless to my toolchain,

Code: Select all

ldd /usr/x86_64-pc-linux-gnu/avr/binutils-bin/2.25.1/ld
        linux-vdso.so.1 (0x0000038206548000)
        libbfd-2.25.1.so => /usr/lib64/libbfd-2.25.1.so (0x0000038205fea000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000038205de6000)
        libc.so.6 => /lib64/libc.so.6 (0x0000038205a3b000)
        libz.so.1 => /lib64/libz.so.1 (0x0000038205823000)
        /lib64/ld-linux-x86-64.so.2 (0x0000038206328000)

libbfd-2.25.1.so => /usr/lib64/libbfd-2.25.1.so (0x0000038205fea000) is always point to the system libbfq instead of the cross-toolchain's. And for older versions,
it cannot find libopcodes stuffs. Manually configuration for ld.so.conf.d may workaround the problem, but similar problem pops up again when compiling GCC.
GCC picks up the wrong target of binuitls and it fails...

Post by **NeddySeagoon** » Fri Oct 30, 2015 5:25 pm

Strange_Attractor,

Code: Select all

ccache version 3.2.3 [enabled]

That means you get to keep the pieces.
Every now and again, ccache returns the wrong answer and you get some strange very hard to debug errors.

Try without using ccache.

I know in doesn't help but armv7a-hardfloat-linux-gnueabi works here on ~amd64 no-multilib when I use crossdev without the -S option.
ARM moves so fast, that its pointless using stable anything.

galanom · Post by **galanom** » Sat Oct 31, 2015 8:32 pm

NeddySeagoon wrote:Try without using ccache.

Hello,
I don't think that's ccache related. I don't have it, yet I had similar issues trying to use crossdev for AVR.
I did an "ldd /usr/libexec/gcc/avr/as" after I saw biergaizi's post and I saw that it could not locate libopcodes-2.25.1.so and libbfd-2.25.1.so.

I tried to include /usr/lib64/binutils/avr/2.25.1 in /etc/ld.so.conf with no luck. Exporting it to LD_LIBRARY_PATH made configure crash earlier. So I just made soft links of these files to /lib64 and it managed to continue. I cannot recall similar problems for ARM.

cwr · Post by **cwr** » Sun Nov 01, 2015 5:38 pm

In April 2015 I built AVR and ARM cross-compilers on a _32_bit_ system with
crossdev 20131011. My notes were:

Using gcc-4.7.3-r1, built avr-gcc with:
USE="-openmp" crossdev -t avr -s4 -S --without-headers
and arm-gcc with:
crossdev -v -S -t armv7-none-linux-gnueabi --env
'EXTRA_ECONF="--with-arch=armv7-a
--with-fpu=vfpv3-d16
--with-float-abi=hard
libc_cv_forced_unwind=yes
libc_cv_ctors_header=yes
libc_cv_c_cleanup=yes"'
It isn't clear if the libc_cv settings are still needed.

I don't know how this translates to a 64-bit system.

(The ARM crosscompiler was used to build software for a BeagleBone Black.)

Will

Strange_Attractor · Post by **Strange_Attractor** » Mon Nov 02, 2015 12:19 am

HalfwayToHeaven wrote:I ran into the same problem as described in the first post, I managed to solve it by doing:
Code: Select all
echo "/usr/lib64/binutils/armv7a-hardfloat-linux-gnueabi/2.22" >/etc/ld.so.conf.d/10armv7a.conf && env-update
And then re-running crossdev. If another version of binutils is used, 2.22 should be replaced by it. To find out where libopcodes-*.so is located:
Code: Select all
find /usr/lib64 -name "libopcodes*"
Not sure why it isn't detected, but this way it will be searched for in the correct path.

Unfortunately this did not work for me. Thanks anyway.

Strange_Attractor · Post by **Strange_Attractor** » Mon Nov 02, 2015 12:21 am

NeddySeagoon wrote:Strange_Attractor,
Code: Select all
ccache version 3.2.3 [enabled]
That means you get to keep the pieces.
Every now and again, ccache returns the wrong answer and you get some strange very hard to debug errors.

Try without using ccache.

I know in doesn't help but armv7a-hardfloat-linux-gnueabi works here on ~amd64 no-multilib when I use crossdev without the -S option.
ARM moves so fast, that its pointless using stable anything.

Maybe I should have mentioned that I had already tried disabling ccache with the same outcome as described above.

firetwister · Post by **firetwister** » Mon Nov 09, 2015 6:28 pm

Skip this workaround, the patch in the bugreport (next post) works fine

I have the same problem.
I did a system rebuild and my crosstoolchains stopped working. This occured on 2 independent computers, so it looks lika a bug to me. My systems are development systems, so I did some unmasking and installed gcc-5.2.0. I'm not complaining

For me the whole issue is a bit more complicated, because the same linker version is used for 3 Architectures on my system. So just adding the search path won't cut it if both crosstolchains use it.

How to fix this the dirty way:
1. Call your cross assembler

Code: Select all

$ armv7a-hardfloat-linux-gnueabi-as
Assembler messages:
Fatal error: selected target format 'elf32-littlearm' unknown

This is the error message we are looking for.

2. Call your cross assembler under strace

Code: Select all

$ strace -eopen armv7a-hardfloat-linux-gnueabi-as
open("/usr/x86_64-pc-linux-gnu/armv7a-hardfloat-linux-gnueabi/lib/tls/x86_64/libopcodes-2.25.1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/x86_64-pc-linux-gnu/armv7a-hardfloat-linux-gnueabi/lib/tls/libopcodes-2.25.1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/x86_64-pc-linux-gnu/armv7a-hardfloat-linux-gnueabi/lib/x86_64/libopcodes-2.25.1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/x86_64-pc-linux-gnu/armv7a-hardfloat-linux-gnueabi/lib/libopcodes-2.25.1.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib64/libopcodes-2.25.1.so", O_RDONLY|O_CLOEXEC) = 3
...

So there is a path, that seems not to be influenced by ld.so.cache, we will use that

3. Find the folder where the correct libopcodes-*.so lies and create a symbolic link to one of the folders found in 2

Code: Select all

# ln -s /usr/lib64/binutils/armv7a-hardfloat-linux-gnueabi/2.25.1/ /usr/x86_64-pc-linux-gnu/armv7a-hardfloat-linux-gnueabi/lib/tls

4. test

Code: Select all

$ armv7a-hardfloat-linux-gnueabi-as
^C
$ rm a.out

5. remember you made a dirty hack, and keep in mind it will break as soon as the binutils version changes

The correct way would probably be by using /etc/env.d.
Could it be that in the past the native libopcodes-*.so was not installed in /usr/lib64/?

firetwister · Post by **firetwister** » Mon Nov 09, 2015 6:48 pm

Looks like binutils-config is broken. There is a patch in the bugreport.
[bug=562460]cross-*/binutils with sys-libs/binutils-libs - executables incorrectly linked to host lib{bfd,opcodes}.so rather than target libraries[/bug]

proteusx · Post by **proteusx** » Mon Nov 16, 2015 9:13 pm

firetwister wrote:Looks like binutils-config is broken. There is a patch in the bugreport.
[bug=562460]cross-*/binutils with sys-libs/binutils-libs - executables incorrectly linked to host lib{bfd,opcodes}.so rather than target libraries[/bug]

Indeed you are correct.
I had the same problem while trying to build a mingw32 toolchain in my new 64 bit Gentoo.
The abovementioned binutils-config patch solved the problem.
Thank you.

P.S. It is interesting that in my old 32 bit Gentoo I could build mingw32 without the patch.

E-Razor · Post by **E-Razor** » Thu Nov 19, 2015 10:25 am

Same issue here with AVR.

Applied the patch, /usr/bin/binutils-config looks correct (patch applied).

But still the same issue.

Any other hints?

--

EDIT:

rebuilding binutils-libs fixed it

Code: Select all

emerge --oneshot sys-libs/binutils-libs sys-devel/binutils cross-avr/binutils

firetwister · Post by **firetwister** » Sun Jul 10, 2016 3:07 pm

I recently ran into the same problem again (see 4 posts earlier), but this time the workaraounds was not possible, because there were no other search dirs before the host binutils libs got loaded.
Strangely I was able to compile a powerpc cross toolchain, but not my desired armv7a-hardfloat-linux-gnueabi, so I suspect something being wrong with my system.

Workaround is quite simple, lasts untill the next rebuild of cross-binutils.

Code: Select all

export LD_RUN_PATH="/usr/lib64/binutils/armv7a-hardfloat-linux-gnueabi/2.25.1"
emerge cross-armv7a-hardfloat-linux-gnueabi/binutils