Bug 926059 – cross-x86_64-w64-mingw32/gcc: fails to compile with "The directory that should contain system headers does not exist: /usr/lib/gcc/x86_64-w64-mingw32/13/include" (make[2]: *** [Makefile:3362: stmp-fixinc] Error 1)

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Abhinav 2024-03-03 01:29:52 UTC]

Mingw32 build of GCC on Gentoo LiveGUI (with no use flag changes) fails in the same way as #905118.

Reproducible: Always

Steps to Reproduce:
1. Start Gentoo LiveGUI
2. webrsync (tested on Mar 2 2024)
3. Add crossdev overlay
4. crossdev --target x86_64-w64-mingw32
Actual Results:  
Build fails with "The directory that should contain system headers does not exist: /usr/lib/gcc/x86_64-w64-mingw32/13/include" (make[2]: *** [Makefile:3362: stmp-fixinc] Error 1), log attached.

Expected Results:  
Builds sucessfully.

Portage 3.0.61 (python 3.11.8-final-0, default/linux/amd64/17.1/desktop/plasma, gcc-13, glibc-2.38-r10, 6.6.13-gentoo-x86_64 x86_64)
=================================================================
System uname: Linux-6.6.13-gentoo-x86_64-x86_64-QEMU_Virtual_CPU_version_2.5+-with-glibc2.38
KiB Mem:    16386144 total,  13131536 free
KiB Swap:          0 total,         0 free
Timestamp of repository gentoo: Sun, 03 Mar 2024 00:45:00 +0000
Head commit of repository gentoo: 0111e3360c6417c924bd7532105ae2b3af371b1f
sh bash 5.1_p16-r6
ld GNU ld (Gentoo 2.41 p5) 2.41.0
app-misc/pax-utils:        1.3.7::gentoo
app-shells/bash:           5.1_p16-r6::gentoo
dev-build/autoconf:        2.71-r6::gentoo
dev-build/automake:        1.16.5-r2::gentoo
dev-build/libtool:         2.4.7-r2::gentoo
dev-build/make:            4.4.1-r1::gentoo
dev-build/meson:           1.3.1-r1::gentoo
dev-java/java-config:      2.3.3-r1::gentoo
dev-lang/perl:             5.38.2-r1::gentoo
dev-lang/python:           3.11.8_p1::gentoo, 3.12.2_p1::gentoo
sys-apps/baselayout:       2.14-r2::gentoo
sys-apps/openrc:           0.53::gentoo
sys-apps/sandbox:          2.38::gentoo
sys-devel/binutils:        2.41-r5::gentoo
sys-devel/binutils-config: 5.5::gentoo
sys-devel/clang:           15.0.7-r3::gentoo, 16.0.6::gentoo, 17.0.6::gentoo
sys-devel/gcc:             13.2.1_p20240113-r1::gentoo
sys-devel/gcc-config:      2.11::gentoo
sys-devel/llvm:            15.0.7-r3::gentoo, 16.0.6::gentoo, 17.0.6::gentoo
sys-kernel/linux-headers:  6.6::gentoo (virtual/os-headers)
sys-libs/glibc:            2.38-r10::gentoo
Repositories:

gentoo
    location: /var/db/repos/gentoo
    sync-type: rsync
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000
    volatile: False
    sync-rsync-verify-jobs: 1
    sync-rsync-extra-opts:
    sync-rsync-verify-max-age: 3
    sync-rsync-verify-metamanifest: yes

Binary Repositories:

gentoobinhost
    priority: 1
    sync-uri: https://distfiles.gentoo.org/releases/amd64/binpackages/17.1/x86-64

ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="@FREE bh-luxi unRAR BAEKMUK LDP-1a mplus-fonts Texinfo-manual CC-PD man-pages-posix-2013 UbuntuFontLicense-1.0 CC-SA-1.0 quake1-textures vlgo"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -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/revdep-rebuild /etc/sandbox.d "
CXXFLAGS="-O2 -pipe"
DISTDIR="/var/cache/distfiles"
EMERGE_DEFAULT_OPTS=" --jobs=8 --load-average=8"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAU"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg-live config-protect-if-modified distlocks ebuild-locks f"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="C.UTF8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
LEX="flex"
LINGUAS="en en-GB en-US"
PKGDIR="/var/cache/binpkgs"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --tim"
PORTAGE_TMPDIR="/var/tmp"
SHELL="/bin/bash"
USE="X a52 aac acl acpi activities alsa amd64 bluetooth branding bzip2 cairo cdda cdr cli crypt cups dbus declarative dri dts dvd dvdr elogind encode exif fl"
Unset:  ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, IS

[Comment 1 Abhinav 2024-03-03 01:30:29 UTC]

Created attachment 886565 [details]
cross-x86_64-w64-mingw32-gcc-stage1.log.xz

[Comment 2 Sam James 2024-03-03 01:38:43 UTC]

For targets where we have to run fixincludes (only two, per the other bug), I guess we sometimes need https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-devel/gcc/files/gcc-13-fix-cross-fixincludes.patch?id=0b75d3ce0bae8240c28c6a8f191f5130548f8475

What I don't yet get is why nobody else reported this until now...

[Comment 3 Abhinav 2024-03-03 01:45:19 UTC]

(In reply to Sam James from comment #2)

> What I don't yet get is why nobody else reported this until now...

I guess because there are few(er) MinGW crossdev users now that we have dev-util/mingw64-toolchain.

[Comment 4 Sam James 2024-03-03 01:48:45 UTC]

(In reply to Abhinav from comment #3)
> (In reply to Sam James from comment #2)
> 
> > What I don't yet get is why nobody else reported this until now...
> 
> I guess because there are few(er) MinGW crossdev users now that we have
> dev-util/mingw64-toolchain.

Yeah, possible. But all of the reporters in the other bug were using mingw via cross, right?

[Comment 5 Sam James 2024-03-03 01:48:59 UTC]

(and they all successfully emerged it after that fixincludes eclsass change)

[Comment 6 Abhinav 2024-03-03 01:55:10 UTC]

(In reply to Sam James from comment #5)
> (and they all successfully emerged it after that fixincludes eclsass change)

My guess would be that a successful crossdev build installs headers to /usr/lib/gcc/x86_64-w64-mingw32/13/include so they are available for subsequent upgrades but not the initial install. And those users may have done the initial install at a time before the patch. I don't know enough about crossdev to confirm this though (but I can see that there are headers in /usr/lib/gcc/x86_64-w64-mingw32/13/include in backups of a system that had a MinGW toolchain installed).

[Comment 7 Abhinav 2024-03-03 01:58:20 UTC]

(In reply to Abhinav from comment #6)

> My guess would be that a successful crossdev build installs headers to
> /usr/lib/gcc/x86_64-w64-mingw32/13/include

Or, at least, at some point in the past it did.

[Comment 8 Sam James 2024-03-03 02:20:37 UTC]

That sounds like a reasonable theory and it's aligned with my suspicion about the original patch we reverted. I think it doesn't take into account the staged build and looks at the real system.

[Comment 9 Chris Henhawke 2024-03-03 14:38:07 UTC]

> What I don't yet get is why nobody else reported this until now...

FWIW, when I hit 925204 it was on an existing install, this sounds like a new install.  I had some free time, so I tried recompiling my existing install again (emerge -1v cross-x86_64-w64-mingw32/gcc), and it seems to build fine... or at least it seemed to get past the point where I had issues the other day... (tree revision be549bab0f447ff65332e4bbdd185d3e95a83fb1)

Unpacked stage3-amd64-openrc-20240229T194908Z.tar.xz to a new chroot, copied /etc/portage to the new chroot and installed crossdev.  Build failed using -j4, so I tried again with -j1 and it also failed as reported. (crossdev -t x86_64-w64-mingw32)

Back on the existing install, -j1 build was successful, so this only seems to affect new installs.

Sorry I wish I could be of more help.  Cheers

[Comment 10 B. Gazotti 2024-03-07 18:31:54 UTC]

> Back on the existing install, -j1 build was successful, so this only seems
> to affect new installs.

I've run into this issue in an existing installation a few days ago, so there's probably something else going on here (is this the right bug?) As to why nobody reported it sooner, mingw64-toolchain was working just fine, and I blamed it on non-standard compiler/flag settings.

Provided patch fixes the issue.

[Comment 11 Sam James 2024-03-07 18:34:59 UTC]

I don't anticipate having time for the next few days to look into this properly, so I'll put back the old patch.

[Comment 12 Larry the Git Cow 2024-03-07 18:37:57 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e4dfb164264174461dd6ac8a826fb01b00e5dbf8

commit e4dfb164264174461dd6ac8a826fb01b00e5dbf8
Author:     Sam James <[e-mail]>
AuthorDate: 2024-03-07 18:36:18 +0000
Commit:     Sam James <[e-mail]>
CommitDate: 2024-03-07 18:36:18 +0000

    Revert "sys-devel/gcc: drop obsolete cross fixincludes patch for 13"
    
    This reverts commit 456eee6e374b50a4d9108a642ca29c5573ac5cb8.
    
    Restore the fixincludes revert. The situation has improved a bit though,
    because we now only run fixincludes when it's truly needed, so having
    this patch is less risky to begin with.
    
    Caveat emptor for trying to remove this in future: make sure to test
    clean builds without mingw already built, and with.
    
    Bug: https://bugs.gentoo.org/905118
    Bug: https://bugs.gentoo.org/925204
    Closes: https://bugs.gentoo.org/926059
    Signed-off-by: Sam James <[e-mail]>

 .../gcc/files/gcc-13-fix-cross-fixincludes.patch      | 19 +++++++++++++++++++
 sys-devel/gcc/gcc-12.3.1_p20240223.ebuild             |  1 +
 sys-devel/gcc/gcc-12.3.1_p20240301.ebuild             |  1 +
 sys-devel/gcc/gcc-13.2.1_p20240113-r1.ebuild          |  1 +
 sys-devel/gcc/gcc-13.2.1_p20240210.ebuild             |  1 +
 sys-devel/gcc/gcc-13.2.1_p20240224.ebuild             |  1 +
 sys-devel/gcc/gcc-13.2.1_p20240302.ebuild             |  1 +
 sys-devel/gcc/gcc-14.0.1_pre20240225.ebuild           |  1 +
 sys-devel/gcc/gcc-14.0.1_pre20240303-r1.ebuild        |  1 +
 9 files changed, 27 insertions(+)