This may be a repeat of 830453 but I can not tell what the failure mode is for that bug report. I am getting "Cannot create executables" on stage 2. I also cannot attach the entire log but can attack what I believe is the relevant piece * Log: /var/log/portage/cross-riscv64-linux-gnu-binutils.log * Emerging cross-binutils ... [ ok ] * Log: /var/log/portage/cross-riscv64-linux-gnu-gcc-stage1.log * Emerging cross-gcc-stage1 ... [ ok ] * Log: /var/log/portage/cross-riscv64-linux-gnu-linux-headers.log * Emerging cross-linux-headers ... [ ok ] * Log: /var/log/portage/cross-riscv64-linux-gnu-glibc.log * Emerging cross-glibc ... [ ok ] * Log: /var/log/portage/cross-riscv64-linux-gnu-gcc-stage2.log * Emerging cross-gcc-stage2 ... checking for riscv64-unknown-linux-gnu-strip... /usr/libexec/gcc/riscv64-unknown-linux-gnu/strip checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking for riscv64-unknown-linux-gnu-gcc... /var/tmp/portage/cross-riscv64-unknown-linux-gnu/gcc-11.2.0/work/build/./gcc/xgcc -B/var/tmp/portage/cross-riscv64-unknown-linux-gnu/gcc-11.2.0/work/build/./gcc/ -B/usr/riscv64-unknown-linux-gnu/bin/ -B/usr/riscv64-unknown-linux-gnu/lib/ -isystem /usr/riscv64-unknown-linux-gnu/include -isystem /usr/riscv64-unknown-linux-gnu/sys-include checking whether the C compiler works... no configure: error: in `/var/tmp/portage/cross-riscv64-unknown-linux-gnu/gcc-11.2.0/work/build/riscv64-unknown-linux-gnu/libgomp': configure: error: C compiler cannot create executables See `config.log' for more details make[1]: *** [Makefile:15275: configure-target-libgomp] Error 1 make[1]: Leaving directory '/var/tmp/portage/cross-riscv64-unknown-linux-gnu/gcc-11.2.0/work/build' make: *** [Makefile:961: all] Error 2
Please do include all the logs, compressed if necessary. You might have to ensure the permissions are right (accessible by your user) or you'll get an error.
Created attachment 763625 [details] cross-riscv64-unknown-linux-gnu-gcc-stage2.log.xz
Created attachment 763626 [details] gcc-config.logs.tar.xz
this is not a permissions error I dont think, i was running as root. I did not think a user could run crossdev -t commands
(In reply to Mark I Manning IV from comment #4) > this is not a permissions error I dont think, i was running as root. > I did not think a user could run crossdev -t commands (I was referring to log-attachment issues, sorry)
lol no that was because i had to ssh from to the problem child from a VM , generate the logs, scp them to the vm the vm then copy them to the vm's host just in order to post them :)
I have exactly the same error. But no cross-compiling. A normal gentoo installation in a qemu virtual machine. No extra cflags. Almost no use flags. Plain vanilla install of gentoo. Updating to gcc-11.2.0 Have tried emerge -ev dev-lang/gcc Nothing helps. No idea if its related but looks very alike :)
Created attachment 764157 [details] sys-devel/gcc-11.2.0/work/build/x86_64-pc-linux-gnu/libgomp/config.log
That "C compiler cannot create executables" error is super generic and happens all the time. Digging into the logs it looks like these are two different issues to me: I see that the original issue (crossdev, from Mark Manning) is configure:3910: checking whether the C compiler works configure:3932: /var/tmp/portage/cross-riscv64-unknown-linux-gnu/gcc-11.2.0/work/build/./gcc/xgcc -B/var/tmp/portage/cross-riscv64-unknown-linux-gnu/gcc-11.2.0/work/build/./gcc/ -B/usr/riscv64-unknown-linux-gnu/bin/ -B/usr/riscv64-unknown-linux-gnu/lib/ -isystem /usr/riscv64-unknown-linux-gnu/include -isystem /usr/riscv64-unknown-linux-gnu/sys-include -g -O2 conftest.c >&5 /usr/libexec/gcc/riscv64-unknown-linux-gnu/ld: cannot find Scrt1.o: No such file or directory collect2: error: ld returned 1 exit status and the second issue (native, from Andreas Nyback) is configure:3910: checking whether the C compiler works configure:3932: /var/tmp/portage/sys-devel/gcc-11.2.0/work/build/./gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-11.2.0/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x 86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fno-checking -g -pipe -march=native -O2 conftest.c >&5 /usr/libexec/gcc/x86_64-pc-linux-gnu/ld: /usr/lib/../lib64/Scrt1.o: in function `_start': (.text+0x12): undefined reference to `__libc_csu_fini' /usr/libexec/gcc/x86_64-pc-linux-gnu/ld: (.text+0x19): undefined reference to `__libc_csu_init' collect2: error: ld returned 1 exit status They might be the same underlying issue (ie, they both look like glibc builds that completed but aren't functional), but it's probably more confusing to mix them together right now. That said, my next step for both would be to look into the glibc builds. I'm using a crossdev toolchain so it at least worked in some configuration at some point, I just re-spun a build right now to see if it blows up on my end. I don't yet have a native Gentoo setup, though. IIUC glibc hasn't released yet (it's slated for today), but just to make sure: you're both on 2.34?
I can reproduce the crossdev failure. After updating to crossdev-20211121 I'm seeing some broken linker search paths, specifically # riscv64-unknown-linux-gnu-gcc -Wl,--verbose ~palmer/test.c -o /tmp/test ... ================================================== /usr/libexec/gcc/riscv64-unknown-linux-gnu/ld: mode elf64lriscv attempt to open /usr/lib/Scrt1.o succeeded /usr/lib/Scrt1.o /usr/libexec/gcc/riscv64-unknown-linux-gnu/ld: /usr/lib/Scrt1.o: relocations in generic ELF (EM: 3) /usr/libexec/gcc/riscv64-unknown-linux-gnu/ld: /usr/lib/Scrt1.o: relocations in generic ELF (EM: 3) /usr/libexec/gcc/riscv64-unknown-linux-gnu/ld: /usr/lib/Scrt1.o: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status Not quite sure how this all fits together in crossdev land, but IIRC there were recently some changes related to library paths being discussed in #gentoo-riscv so that smells like it might be related.
Created attachment 764187 [details] crossdev-riscv64.sh So one of the things I have learned over the years w/ crossdev and mips toolchains, is that it is better to build a cross-toolchain in stages rather than one-shot it. No idea why this works better, but it does. Try the attached script, making sure to edit the variables inside to your liking. It's based off the one I use for creating mips64 toolchains locally on my dev box, just tweaked for riscv64 targets. Basic gist is, for stages 2 and 4, we do not pass in ASFLAGS/LDFLAGS/CFLAGS. Those only apply during stage3 (the C lib phase). So set the CFLAGS to your liking in the stage3() function. From what I could read, riscv doesn't have defaults for -march/-mtune/-mabi, so you have to select the best ones for your target platform. I picked the double-float 64-bit ones on a whim. That all said, it looks like this missing "Scrt1.o" issue is a problem with glibc itself for the riscv64-unknown-linux-gnu target, as I ran into it while initially building stage4 (full gcc). You will want to file a bug with glibc upstream to get them to look into it. Building a riscv64 cross-toolchain + gdb-11.2 using the musl C library went through without issue, which is what leads me to believe it's a glibc bug. You can switch between building one or the other in the script by commenting/uncommenting the appropriate variables (musl is currently selected). Removing a toolchain, you have to run crossdev -C riscv64-unknown-linux-<foo>, where <foo> is your C Lib target, then answer 'y' at the prompt. Recommend doing this if you need to replace a specific CHOST target with a new one or updated toolchain bits. You have to set the specific versions for gcc/lib/binutils/headers in the script too. I really should make this script smarter about things, but it's really a gross hackjob that makes building mips64 toolchains rather easy.
(In reply to Andreas Nyback from comment #7) > I have exactly the same error. But no cross-compiling. A normal gentoo > installation in a qemu virtual machine. No extra cflags. Almost no use > flags. Plain vanilla install of gentoo. Updating to gcc-11.2.0 > Have tried emerge -ev dev-lang/gcc > Nothing helps. > No idea if its related but looks very alike :) Andreas: what's your emerge --info
Mark: the output of find /usr/riscv64-unknown-linux-gnu and of ls -l /usr/riscv64-unknown-linux-gnu/etc/portage after the failing crossdev command would be helpful also, please attach /usr/riscv64-unknown-linux-gnu/etc/portage/make.conf
(In reply to Joshua Kinard from comment #11) > Created attachment 764187 [details] > crossdev-riscv64.sh > > So one of the things I have learned over the years w/ crossdev and mips > toolchains, is that it is better to build a cross-toolchain in stages rather > than one-shot it. Right, and it's possible that this works. We should try to fix the underlying issue though. (Which most likely is somewhere in profiles or in multilib.eclass. Or alternatively a needed fix in toolchain.eclass, who knows.)
(In reply to Andreas K. Hüttel from comment #13) > Mark: the output of > > find /usr/riscv64-unknown-linux-gnu > > and of > > ls -l /usr/riscv64-unknown-linux-gnu/etc/portage > > after the failing crossdev command would be helpful > > also, please attach /usr/riscv64-unknown-linux-gnu/etc/portage/make.conf Oh and one more question, are you trying to build a multilib crossdev? Because that is quite Unsupported, right now. (for riscv)
(In reply to Andreas K. Hüttel from comment #14) > (In reply to Joshua Kinard from comment #11) > > (Which most likely is somewhere in profiles or in multilib.eclass. > Or alternatively a needed fix in toolchain.eclass, who knows.) It feels more like a glibc bug to me when configured for a cross-target, since all of the Gentoo pieces look to work fine for the musl CHOST, but not the GNU CHOST. MIPS has a bit of a sordid history in the early days w/ the GNU toolchain and cross-compilers because of the dizzying permutations of ISAs and ABIs making things complicated. RiscV is said to inherit a number of design philosophies from MIPS, so I can't rule out that some of our old bugs may return again to haunt RiscV.
OK problem reproduced. Preliminary diagnosis, for whatever reason stage2 gcc gets configured such that it searches (64bit) libraries in /lib (not in /lib64). From the spec file in the stage2 build: *startfile_prefix_spec: /lib%{march=rv32*:32}%{march=rv64*:64}/%{mabi=ilp32:ilp32}%{mabi=ilp32e:ilp32e}%{mabi=ilp32f:ilp32f}%{mabi=ilp32d:ilp32d}%{mabi=lp64:lp64}%{mabi=lp64f:lp64f}%{mabi=lp64d:lp64d}/ /usr/lib%{march=rv32*:32}%{march=rv64*:64}/%{mabi=ilp32:ilp32}%{mabi=ilp32e:ilp32e}%{mabi=ilp32f:ilp32f}%{mabi=ilp32d:ilp32d}%{mabi=lp64:lp64}%{mabi=lp64f:lp64f}%{mabi=lp64d:lp64d}/ /lib/ /usr/lib/ The first definition is the two-stage path (e.g. /lib32/ilp32) The second definition is the /usr two-stage path And as third and fourth definition follow /lib and /usr/lib (which should be /lib64 and /usr/lib64). As for the reason for that... this will require some more searching (and probably a black cat and a rooster at midnight). Probably some configuring automagic gone wild.
Comment on attachment 764187 [details] crossdev-riscv64.sh Script is nice but is not gonna help here.
(In reply to Andreas K. Hüttel from comment #18) > Comment on attachment 764187 [details] > crossdev-riscv64.sh > > Script is nice but is not gonna help here. No worries, just trying to help out where I think I can.
Created attachment 764417 [details, diff] patch for catalyst Please test the attached patch for catalyst (easiest by running patch /usr/bin/catalyst < 0001-Add-some-special-riscv-sauce.-Ugly.patch )...
Created attachment 764432 [details] ls -l /usr/riscv64-unknown-linux-gnu/etc/portage
(In reply to Andreas K. Hüttel from comment #20) > Created attachment 764417 [details, diff] [details, diff] > patch for catalyst > > Please test the attached patch for catalyst (easiest by running > > patch /usr/bin/catalyst < 0001-Add-some-special-riscv-sauce.-Ugly.patch > > )... s/catalyst/crossdev/
(In reply to Andreas K. Hüttel from comment #13) > Mark: the output of > > find /usr/riscv64-unknown-linux-gnu > > and of > > ls -l /usr/riscv64-unknown-linux-gnu/etc/portage > > after the failing crossdev command would be helpful > > also, please attach /usr/riscv64-unknown-linux-gnu/etc/portage/make.conf -rw-r--r-- 1 root root 669 Feb 6 01:02 make.conf lrwxrwxrwx 1 root root 38 Jan 31 12:16 make.profile -> /var/db/repos/gentoo/profiles/embedded drwxr-xr-x 2 root root 4096 Feb 6 01:02 profile i attached find /usr/riscv64-unknown-linux-gnu but miss labeled it.
Created attachment 764435 [details] usr/riscv64-unknown-linux-gnu/etc/portage/make.conf
(In reply to Andreas K. Hüttel from comment #15) > (In reply to Andreas K. Hüttel from comment #13) > > Mark: the output of > > > > find /usr/riscv64-unknown-linux-gnu > > > > and of > > > > ls -l /usr/riscv64-unknown-linux-gnu/etc/portage > > > > after the failing crossdev command would be helpful > > > > also, please attach /usr/riscv64-unknown-linux-gnu/etc/portage/make.conf > > Oh and one more question, are you trying to build a multilib crossdev? > > Because that is quite Unsupported, right now. (for riscv) umn... how do i tell? :)
(In reply to Mark I Manning IV from comment #21) > Created attachment 764432 [details] > ls -l /usr/riscv64-unknown-linux-gnu/etc/portage this was find /usr/riscv64-unknown-linux-gnu not the ls command
(In reply to Mark I Manning IV from comment #26) > (In reply to Mark I Manning IV from comment #21) > > Created attachment 764432 [details] > > ls -l /usr/riscv64-unknown-linux-gnu/etc/portage > > this was find /usr/riscv64-unknown-linux-gnu not the ls command oopts :) see attached
Created attachment 765199 [details] find /usr/riscv64-unknown-linux-gnu
(In reply to Mark I Manning IV from comment #28) > Created attachment 765199 [details] > find /usr/riscv64-unknown-linux-gnu did you try the patch? also: https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=63338c99d5ee1e5b3b6d4eb99f4ddf438c36917e Will be in tagged crossdev soon.
From 63338c99d5ee1e5b3b6d4eb99f4ddf438c36917e Mon Sep 17 00:00:00 2001 From: "Andreas K. Hüttel" <dilfridge@gentoo.org> Date: Sat, 5 Feb 2022 19:35:11 +0100 Subject: Add some special riscv sauce. Ugly. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit This is necessary since * for glibc, the "fallback" libdir for 64bit is lib64 * for gcc, the "fallback" libdir for 64bit is lib By providing the full multilib libdirs and a compatibility symlink as in baselayout, the pieces fit together again. riscv32 is kinda not affected since both gcc and glibc use lib (NOT lib32, as in the multilib libdirs). Signed-off-by: Andreas K. Hüttel <dilfridge@gentoo.org> ---
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=90086142b8928c12c36fafaac816810e83e5cae4 commit 90086142b8928c12c36fafaac816810e83e5cae4 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-02-20 02:01:39 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-02-20 02:01:39 +0000 sys-devel/crossdev: add 20220205 Closes: https://bugs.gentoo.org/832059 Closes: https://bugs.gentoo.org/830453 Signed-off-by: Sam James <sam@gentoo.org> sys-devel/crossdev/Manifest | 1 + sys-devel/crossdev/crossdev-20220205.ebuild | 36 +++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+)
many thanks to all the devs and other people who worked to resolve this!
