Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 666880

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

Description Andrius Štikonas 2018-09-23 16:12:23 UTC
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
Comment 1 Andrius Štikonas 2018-09-23 16:12:44 UTC
Created attachment 547644 [details]
cross-aarch64-unknown-linux-gnu-gcc-stage1.log.xz

cross-aarch64-unknown-linux-gnu-gcc-stage1.log.xz
Comment 2 Andrius Štikonas 2018-09-23 16:13:03 UTC
Created attachment 547646 [details]
gcc-config.logs.tar.xz
Comment 3 Andrius Štikonas 2018-09-23 16:16:56 UTC
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
Comment 4 Captain Crutches 2018-09-24 03:05:00 UTC
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
Comment 5 Captain Crutches 2018-09-24 03:05:37 UTC
Created attachment 547738 [details]
cross-x86_64-w64-mingw32-gcc-stage1.log.xz
Comment 6 Captain Crutches 2018-09-24 03:06:20 UTC
Created attachment 547740 [details]
cross-x86_64-w64-mingw32-info.log
Comment 7 Jeroen Roovers (RETIRED) gentoo-dev 2018-09-25 12:13:21 UTC
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
Comment 8 Sergei Trofimovich (RETIRED) gentoo-dev 2018-09-25 22:00:50 UTC
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.
Comment 9 Andrius Štikonas 2018-09-25 23:59:51 UTC
(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.
Comment 10 Captain Crutches 2018-09-26 01:47:43 UTC
No joy here, for x86_64-w64-mingw32 it still fails with the same error as before.
Comment 11 Andrius Štikonas 2018-09-30 22:23:37 UTC
(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".
Comment 12 Sergei Trofimovich (RETIRED) gentoo-dev 2018-10-18 22:20:40 UTC
(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
Comment 13 Larry the Git Cow gentoo-dev 2018-10-18 22:26:42 UTC
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(-)
Comment 14 Sergei Trofimovich (RETIRED) gentoo-dev 2018-10-18 22:30:34 UTC
(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.
Comment 15 Captain Crutches 2018-10-18 22:49:20 UTC
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?
Comment 16 Sergei Trofimovich (RETIRED) gentoo-dev 2018-10-18 23:03:12 UTC
(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).
Comment 17 Captain Crutches 2018-10-19 00:39:31 UTC
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!