Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Cannot compile cross-toolchain for armv7a
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
Strange_Attractor
n00b
n00b


Joined: 07 Mar 2011
Posts: 36
Location: Sweden

PostPosted: Sun Oct 04, 2015 3:48 pm    Post subject: Cannot compile cross-toolchain for armv7a Reply with quote

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:
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:

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.
Back to top
View user's profile Send private message
Strange_Attractor
n00b
n00b


Joined: 07 Mar 2011
Posts: 36
Location: Sweden

PostPosted: Sun Oct 04, 2015 5:25 pm    Post subject: Update Reply with quote

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:
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.
Back to top
View user's profile Send private message
Strange_Attractor
n00b
n00b


Joined: 07 Mar 2011
Posts: 36
Location: Sweden

PostPosted: Thu Oct 08, 2015 11:47 am    Post subject: Reply with quote

Does noone have any idea? Should I file a bug report?
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2971
Location: Germany

PostPosted: Thu Oct 08, 2015 11:57 am    Post subject: Reply with quote

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?
Back to top
View user's profile Send private message
Strange_Attractor
n00b
n00b


Joined: 07 Mar 2011
Posts: 36
Location: Sweden

PostPosted: Thu Oct 08, 2015 2:07 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
frostschutz
Advocate
Advocate


Joined: 22 Feb 2005
Posts: 2971
Location: Germany

PostPosted: Thu Oct 08, 2015 2:27 pm    Post subject: Reply with quote

emerge --info?

I'm on ~amd64 in case that matters...
Back to top
View user's profile Send private message
Strange_Attractor
n00b
n00b


Joined: 07 Mar 2011
Posts: 36
Location: Sweden

PostPosted: Thu Oct 08, 2015 2:38 pm    Post subject: Reply with quote

emerge --info output:
Code:

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
Back to top
View user's profile Send private message
HalfwayToHeaven
n00b
n00b


Joined: 12 Oct 2015
Posts: 1

PostPosted: Mon Oct 12, 2015 7:49 pm    Post subject: Reply with quote

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

Code:
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:
find /usr/lib64 -name "libopcodes*"


Not sure why it isn't detected, but this way it will be searched for in the correct path.
Back to top
View user's profile Send private message
biergaizi
n00b
n00b


Joined: 18 Dec 2011
Posts: 45
Location: Beijing, China

PostPosted: Fri Oct 30, 2015 5:05 pm    Post subject: Reply with quote

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:

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...
_________________
Keep It Simple, stupid.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 45782
Location: 56N 3W

PostPosted: Fri Oct 30, 2015 5:25 pm    Post subject: Reply with quote

Strange_Attractor,

emerge --info:
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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
galanom
n00b
n00b


Joined: 24 Oct 2011
Posts: 26

PostPosted: Sat Oct 31, 2015 8:32 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
cwr
Veteran
Veteran


Joined: 17 Dec 2005
Posts: 1969

PostPosted: Sun Nov 01, 2015 5:38 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Strange_Attractor
n00b
n00b


Joined: 07 Mar 2011
Posts: 36
Location: Sweden

PostPosted: Mon Nov 02, 2015 12:19 am    Post subject: Reply with quote

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

Code:
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:
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.
Back to top
View user's profile Send private message
Strange_Attractor
n00b
n00b


Joined: 07 Mar 2011
Posts: 36
Location: Sweden

PostPosted: Mon Nov 02, 2015 12:21 am    Post subject: Reply with quote

NeddySeagoon wrote:
Strange_Attractor,

emerge --info:
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.
Back to top
View user's profile Send private message
firetwister
n00b
n00b


Joined: 09 Feb 2005
Posts: 51

PostPosted: Mon Nov 09, 2015 6:28 pm    Post subject: Reply with quote

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:
$ 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:
$ 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:
# 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:
$ 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/?


Last edited by firetwister on Mon Nov 09, 2015 8:45 pm; edited 1 time in total
Back to top
View user's profile Send private message
firetwister
n00b
n00b


Joined: 09 Feb 2005
Posts: 51

PostPosted: Mon Nov 09, 2015 6:48 pm    Post subject: Reply with quote

Looks like binutils-config is broken. There is a patch in the bugreport.
cross-*/binutils with sys-libs/binutils-libs - executables incorrectly linked to host lib{bfd,opcodes}.so rather than target libraries
Back to top
View user's profile Send private message
proteusx
Apprentice
Apprentice


Joined: 21 Jan 2008
Posts: 289

PostPosted: Mon Nov 16, 2015 9:13 pm    Post subject: Reply with quote

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

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.
Back to top
View user's profile Send private message
E-Razor
n00b
n00b


Joined: 11 Jul 2004
Posts: 67

PostPosted: Thu Nov 19, 2015 10:25 am    Post subject: Reply with quote

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:

emerge --oneshot sys-libs/binutils-libs sys-devel/binutils cross-avr/binutils
Back to top
View user's profile Send private message
firetwister
n00b
n00b


Joined: 09 Feb 2005
Posts: 51

PostPosted: Sun Jul 10, 2016 3:07 pm    Post subject: Reply with quote

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:

export LD_RUN_PATH="/usr/lib64/binutils/armv7a-hardfloat-linux-gnueabi/2.25.1"
emerge cross-armv7a-hardfloat-linux-gnueabi/binutils
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum