Summary: | configure: error: in `/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-7.3.0-r3/work/build/aarch64-unknown-linux-gnu/libmpx': configure: error: C compiler cannot create executables | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrius Štikonas <andrius> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | captaincrutches, slyfox |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 627914 | ||
Attachments: |
cross-aarch64-unknown-linux-gnu-info.log
cross-aarch64-unknown-linux-gnu-gcc-stage1.log.xz gcc-config.logs.tar.xz cross-x86_64-w64-mingw32-gcc-stage1.log.xz cross-x86_64-w64-mingw32-info.log |
Created attachment 547644 [details]
cross-aarch64-unknown-linux-gnu-gcc-stage1.log.xz
cross-aarch64-unknown-linux-gnu-gcc-stage1.log.xz
Created attachment 547646 [details]
gcc-config.logs.tar.xz
If I can read logs correctly, the error seems to be: configure:3277: /var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-7.3.0-r3/work/build/./gcc/xgcc -B/var/tmp/portage/cross-aarch64-unknown-linux-gnu/gcc-7.3.0-r3/work/build/./gcc/ -B/usr/aarch64-unknown-linux-gnu/bin/ -B/usr/aarch64-unknown-linux-gnu/lib/ -isystem /usr/aarch64-unknown-linux-gnu/include -isystem /usr/aarch64-unknown-linux-gnu/sys-include -g -O2 conftest.c >&5 /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: cannot find Scrt1.o: No such file or directory /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: cannot find crti.o: No such file or directory /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: cannot find -lc /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: cannot find crtn.o: No such file or directory collect2: error: ld returned 1 exit status configure:3281: $? = 1 I'm having a similar problem building for mingw32: it's having trouble finding a crt-related library. Command: crossdev -t x86_64-w64-mingw32 /usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find dllcrt2.o: No such file or directory /usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -lmingwthrd /usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -lmingw32 /usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -lmingwex /usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -lmoldname /usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -lmsvcrt /usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -ladvapi32 /usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -lshell32 /usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -luser32 /usr/libexec/gcc/x86_64-w64-mingw32/ld: cannot find -lkernel32 collect2: error: ld returned 1 exit status Created attachment 547738 [details]
cross-x86_64-w64-mingw32-gcc-stage1.log.xz
Created attachment 547740 [details]
cross-x86_64-w64-mingw32-info.log
tarfile::./build/aarch64-unknown-linux-gnu/libmpx/config.log: /usr/libexec/gcc/aarch64-unknown-linux-gnu/ld: cannot find Scrt1.o: No such file or directory I think first failure (aarch64) is caused by USE=mpx enabled by default and the second is caused by USE=jit enabled by default. As a workaround try: USE="-mpx -jit" crossdev -t <target> It if works we'll figure something out. (In reply to Sergei Trofimovich from comment #8) > I think first failure (aarch64) is caused by USE=mpx enabled by default and > the second is caused by USE=jit enabled by default. > > As a workaround try: > USE="-mpx -jit" crossdev -t <target> > It if works we'll figure something out. It helped a bit. Now it fails at gcc-stage2. I'll investigate the error some other day. No joy here, for x86_64-w64-mingw32 it still fails with the same error as before. (In reply to Andrius Štikonas from comment #9) > (In reply to Sergei Trofimovich from comment #8) > > I think first failure (aarch64) is caused by USE=mpx enabled by default and > > the second is caused by USE=jit enabled by default. > > > > As a workaround try: > > USE="-mpx -jit" crossdev -t <target> > > It if works we'll figure something out. > > It helped a bit. Now it fails at gcc-stage2. I'll investigate the error some > other day. Ok, it seems it builds if I further disable USE="-go". Otherwise it prints error go1: error: unknown value ‘native’ for -march. Which of course makes sense, although, I don't know why build system attempts to use "native". (In reply to Andrius Štikonas from comment #11) > (In reply to Andrius Štikonas from comment #9) > > (In reply to Sergei Trofimovich from comment #8) > > > I think first failure (aarch64) is caused by USE=mpx enabled by default and > > > the second is caused by USE=jit enabled by default. > > > > > > As a workaround try: > > > USE="-mpx -jit" crossdev -t <target> > > > It if works we'll figure something out. > > > > It helped a bit. Now it fails at gcc-stage2. I'll investigate the error some > > other day. > > Ok, it seems it builds if I further disable USE="-go". Otherwise it prints > error > go1: error: unknown value ‘native’ for -march. > > Which of course makes sense, although, I don't know why build system > attempts to use "native". This might have been fixed by bug #581406 The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=82edc6ad7e32ad28dce50153ca9a2de17c3afcf8 commit 82edc6ad7e32ad28dce50153ca9a2de17c3afcf8 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2018-10-18 22:24:46 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2018-10-18 22:24:46 +0000 crossdev: disable USE=jit and USE=mpx gcc-stage1 jit and mpx need working libc to link against it. gcc-stage1 is too early for it. Disable those as well. Reported-by: Andrius Štikonas Bug: https://bugs.gentoo.org/666880 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> crossdev | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (In reply to Captain Crutches from comment #10) > No joy here, for x86_64-w64-mingw32 it still fails with the same error as > before. Can you post full build log with USE=-jit? It is supposed to at least not build jit. Perhaps something else pulls in libgcc_s. Is that not what I've already uploaded? cross-x86_64-w64-mingw32-gcc-stage1.log.xz? My package.use has: cross-x86_64-w64-mingw32/binutils -multilib cross-x86_64-w64-mingw32/mingw64-runtime -mpx -jit -selinux headers-only -multilib cross-x86_64-w64-mingw32/gcc -sanitize -vtv -pie nopie -mpx -jit -selinux -boundschecking -d -gcj -gtk -libffi -mudflap -objc -objc++ -objc-gc -fortran -go -cxx -openmp -sanitize -vtv -multilib so I assume that means it's not building jit... unless I'm missing something. Should I try building it without the crossdev command? (In reply to Captain Crutches from comment #15) > Is that not what I've already uploaded? > cross-x86_64-w64-mingw32-gcc-stage1.log.xz? > > My package.use has: > cross-x86_64-w64-mingw32/binutils -multilib > cross-x86_64-w64-mingw32/mingw64-runtime -mpx -jit -selinux headers-only > -multilib > cross-x86_64-w64-mingw32/gcc -sanitize -vtv -pie nopie -mpx -jit -selinux > -boundschecking -d -gcj -gtk -libffi -mudflap -objc -objc++ -objc-gc > -fortran -go -cxx -openmp -sanitize -vtv -multilib > > so I assume that means it's not building jit... unless I'm missing > something. Should I try building it without the crossdev command? The one you have uploaded has '--enable-languages=c,jit'. Another suspicious line is: /var/tmp/portage/cross-x86_64-w64-mingw32/gcc-8.2.0-r2/temp/environment: line 4440: built_with_use: command not found built_with_use was removed quite a while ago: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1df6e6dc6c406541eff5be543659b76b4e909da4 Make sure your crossdev overlay uses up-to-date toolchain.eclass and gcc ebuilds (and not some other copy). I realized right after posting my last comment that the build log I uploaded may have been from before I applied the USE changes, so I just tried again... but the log still contains both of the lines you mentioned. My crossdev overlay (/usr/crossdev-overlay) symlinks its category folders directly to my main portage directory: # ls -l /usr/crossdev-overlay/cross-x86_64-w64-mingw32/ total 0 lrwxrwxrwx 1 root root 31 Sep 24 01:07 binutils -> /usr/portage/sys-devel/binutils lrwxrwxrwx 1 root root 26 Sep 24 01:08 gcc -> /usr/portage/sys-devel/gcc lrwxrwxrwx 1 root root 26 Sep 24 01:07 gdb -> /usr/portage/sys-devel/gdb lrwxrwxrwx 1 root root 37 Sep 24 01:07 mingw64-runtime -> /usr/portage/dev-util/mingw64-runtime so I can only assume that means it's using up-to-date ebuilds. HOWEVER, as I write this, I see that I have a toolchain.eclass from a different overlay (gentoo-gpu). That's an old overlay and I don't have anything installed from there, so I'm removing it and trying again, hoping the default toolchain.eclass will help... And wouldn't you know it, it did! Past gcc-stage1 and on to gcc-stage2, so I think my problem was not this bug. Thanks for the tip! |
Created attachment 547642 [details] cross-aarch64-unknown-linux-gnu-info.log I tried a few different platforms but always the same result: failure to build gcc stage1