When using ld.gold it reports in as GNU gold (Gentoo 2.29.1 p3 2.29.1) 1.14 compared to ld.bfd, which reports as GNU ld (Gentoo 2.29.1 p3) 2.29.1 Crossdev now, when invoked with crossdev -t armv7a-hardfloat-linux-gnueabi --b 2.29.1-r1 --g 7.2.0 --k 4.4 --l 2.25-r9 will fail at glibc, by saying: configure: error: *** These critical programs are missing or too old: ld Switching to ld.bfd remedies this issue, but it would be nice to have either gold report the version compatible to bfd (if that is applicable or makes any sense) - or to have cross-glibc check for a minimal bfd or gold version or use the bfd linker by default if required....
Thank you for the report. Please *attach* the logfiles, https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide#Report_a_build-time_bug_.28emerge_failed.29 and reopen this ticket (Status:unconfirmed).
Created attachment 521226 [details] cross-armv7a-hardfloat-linux-gnueabi-info.log
Created attachment 521228 [details] cross-armv7a-hardfloat-linux-gnueabi-glibc-headers.log.xz checking version of /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld... v. ?.??, bad
Created attachment 521230 [details] glibc-config.logs.tar.xz
Retried with crossdev-20180120 GNU ld (Gentoo 2.30 p1) 2.30.0 (success) GNU gold (Gentoo 2.30 p1 2.30.0) 1.15 (fail) GNU gold is logged as checking version of /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld... v. ?.??, bad (see attachement #521228)
Created attachment 521232 [details] emerge --info
> checking for armv7a-hardfloat-linux-gnueabi-gcc... x86_64-pc-linux-gnu-gcc ... > configure: WARNING: using cross tools not prefixed with host triplet ... > checking for armv7a-hardfloat-linux-gnueabi-nm... gcc-nm Something is very wrong here. It tries to use you build compiler as a crosscompiler. My guess is ccache breaking an armv7a-hardfloat-linux-gnueabi-gcc symlink for you. Does disabling FEATURES=-ccache make things work again?
(In reply to Sergei Trofimovich from comment #7) > > checking for armv7a-hardfloat-linux-gnueabi-gcc... x86_64-pc-linux-gnu-gcc > ... > > configure: WARNING: using cross tools not prefixed with host triplet > ... > > checking for armv7a-hardfloat-linux-gnueabi-nm... gcc-nm > > Something is very wrong here. It tries to use you build compiler as a > crosscompiler. > > My guess is ccache breaking an armv7a-hardfloat-linux-gnueabi-gcc symlink > for you. > > Does disabling FEATURES=-ccache make things work again? Thank you Sergei, unfortunately disabling ccache (even unmerging and deleting all leftovers) doesn't change the situation. The message about the triplet is still appearing (with gold and bfd) With gold it still fails, with bfd it works.... But far as I can see, that message appears when emerging glibc-headers, not glibc. the cross-gcc can't exist at that time, because it requires the glibc headers. right after glibc-headers are installed, it builds the cross-gcc. after that, it builds cross-glibc. cross-glibc emits the message: "checking for sysdeps preconfigure fragments... aarch64 alpha arm configure: Found compiler is configured for armv7" which seems sound. So I guess that it's really the gold linker messing with versions here....
(In reply to Walter Hüttenmeyer from comment #8) > the cross-gcc can't exist at that time, because it requires the glibc > headers. Ah, good point! I've totally missed it. > right after glibc-headers are installed, it builds the cross-gcc. > after that, it builds cross-glibc. > > cross-glibc emits the message: > "checking for sysdeps preconfigure fragments... aarch64 alpha arm configure: > Found compiler is configured for armv7" > > which seems sound. So I guess that it's really the gold linker messing with > versions here.... Yeah, let's investigate why it fails to detect linker version. I've reproduced the failure locally as well. Versions reported for .bfd and .gold are very curious: $ /usr/lib/gcc/i686-pc-linux-gnu/5.4.0/../../../../i686-pc-linux-gnu/bin/ld.bfd -v GNU ld (Gentoo 2.29.1 p3) 2.29.1 $ /usr/lib/gcc/i686-pc-linux-gnu/5.4.0/../../../../i686-pc-linux-gnu/bin/ld -v GNU gold (Gentoo 2.29.1 p3 2.29.1) 1.14
glibc's configure does the following detection: ac_prog_version=`$LD --version 2>&1 | sed -n 's/^.*GNU ld.* \([0-9][0-9]*\.[0-9.]*\).*$/\1/p'` case $ac_prog_version in '') ac_prog_version="v. ?.??, bad"; ac_verc_fail=yes;; $ ld --version 2>&1 | sed -n 's/^.*GNU ld.* \([0-9][0-9]*\.[0-9.]*\).*$/\1/p' 2.29.1 (against "GNU ld (Gentoo 2.29.1 p3) 2.29.1" string) $ ld.gold --version 2>&1 | sed -n 's/^.*GNU ld.* \([0-9][0-9]*\.[0-9.]*\).*$/\1/p' <empty> (against "GNU gold (Gentoo 2.29.1 p3 2.29.1) 1.14" string)
It was fixed upstream in glibc-2.26: https://sourceware.org/PR14995 https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff;h=f300dc7358e785dd92259514f57acd10f695d142
(In reply to Sergei Trofimovich from comment #11) > It was fixed upstream in glibc-2.26: https://sourceware.org/PR14995 > > https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commitdiff; > h=f300dc7358e785dd92259514f57acd10f695d142 I've tried to run crossdev with glibc-2.26-r6, and yes - you are right. No more fighting with crossdev, it works! Thank you very much for guiding me through this, Sergei! From my side, this could be closed - thank you very much again!
