On Mon, 4 Apr 2022, Christer Solskogen wrote:
On 04.04.2022 15:37, Martin Storsjö wrote:
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).
x86_64-w64-mingw32-dlltool --as-flags=--32 -m i386 -k
--as=x86_64-w64-mingw32-as --output-lib lib32/libd3dx9.a --temp-prefix
$(basename lib32/libd3dx9.a .a) --input-def
/home/builder/mingw-w64/mingw-w64-crt/lib32/d3dx9_43.def
x86_64-w64-mingw32-dlltool: lib32/libd3dx9.a: error reading libd3dx9h.o:
file truncated
As I have a workaround I'll wait until a newer binutils is released, and
check if it happens there as well.
FWIW, I got another mention of this issue now, and with that I realized
what the issue was - this only happens if building both lib32 and lib64 at
the same time (which admittedly is the default; all my test builds have
been done with --disable-lib32 for x86_64 builds, or vice versa).
See the patch I just posted to the mailing list; "crt: Fix building
lib32+lib64 in parallel", which should fix this issue.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
