On Mon, 4 Apr 2022, Christer Solskogen wrote:
I'm cross compiling mingw-w64-crt on Linux and sometimes compiling mingw-w64
(v10) fails when using a high(ish) number to make -j. -j8 sometimes fails,
-j4 seems to work.
builder@champ:/tmp/build/mingw-w64-crt$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/tmp/cross-mingw-w64/lib/gcc/x86_64-w64-mingw32/11.2.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: /home/builder/gcc/configure --prefix=/tmp/cross-mingw-w64
--libexecdir=/tmp/cross-mingw-w64/lib --target=x86_64-w64-mingw32
--enable-languages=c,c++ --disable-libstdcxx-pch --enable-libgomp
--enable-threads=posix --with-sysroot=/tmp/cross-mingw-w64
--with-checking=release --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC)
builder@champ:/tmp/build/mingw-w64-crt$ x86_64-w64-mingw32-ld -v
GNU ld (GNU Binutils) 2.38
Known problem, or something to file a bug for?
This sounds a lot like
https://sourceware.org/bugzilla/show_bug.cgi?id=28885 - but that one
wouldn't manifest if you're building the v10 release, only with older
releases. (In latest mingw-w64, that bug would be masked by
0ad299826ca14987fd53664c1047f4dfe848c3f8.)
To have any clue about what it is, if it isn't this, you'd need to provide
the build log, along with the command that failed and its output (which
usually would be buried somewhere in the build log, if building with lots
of parallel jobs).
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
