Created attachment 14857 [details] step 1 and 2 result of libkernel32.a The last working version of binutils which makes a mingw (x86) -> mingw64-64 (x86/x64) build possible for me is version 2.32. I am able to build binutils 2.40 for example, but building mingw-w64-crt 10.0.0 later fails with the following error: x86_64-w64-mingw32-ranlib.exe: lib32/libkernel32.a: file format not recognized The last steps to create this library were the following: x86_64-w64-mingw32-dlltool --as-flags=--32 -m i386 -k --as=x86_64-w64-mingw32-as --output-lib lib32/libkernel32.a --temp-prefix $(basename lib32/libkernel32.a .a) --input-def ../../src/mingw-w64-v10.0.0/mingw-w64-crt/`echo lib32/libkernel32.a | /bin/sed 's|/lib|/|;s|\.a|.def|'` x86_64-w64-mingw32-ar cru lib32/libkernel32.a intrincs/lib32_libkernel32_a-__movsb.o intrincs/lib32_libkernel32_a-__movsd.o intrincs/lib32_libkernel32_a-__movsw.o intrincs/lib32_libkernel32_a-__stosb.o intrincs/lib32_libkernel32_a-__stosd.o intrincs/lib32_libkernel32_a-__stosw.o intrincs/lib32_libkernel32_a-_rotl64.o intrincs/lib32_libkernel32_a-_rotr64.o intrincs/lib32_libkernel32_a-bitscanfwd.o intrincs/lib32_libkernel32_a-bitscanrev.o intrincs/lib32_libkernel32_a-bittest.o intrincs/lib32_libkernel32_a-bittestc.o intrincs/lib32_libkernel32_a-bittestci.o intrincs/lib32_libkernel32_a-bittestr.o intrincs/lib32_libkernel32_a-bittestri.o intrincs/lib32_libkernel32_a-bittests.o intrincs/lib32_libkernel32_a-bittestsi.o intrincs/lib32_libkernel32_a-cpuid.o intrincs/lib32_libkernel32_a-ilockadd.o intrincs/lib32_libkernel32_a-ilockand.o intrincs/lib32_libkernel32_a-ilockand64.o intrincs/lib32_libkernel32_a-ilockcxch.o intrincs/lib32_libkernel32_a-ilockcxch16.o intrincs/lib32_libkernel32_a-ilockcxch64.o intrincs/lib32_libkernel32_a-ilockcxchptr.o intrincs/lib32_libkernel32_a-ilockdec.o intrincs/lib32_libkernel32_a-ilockdec16.o intrincs/lib32_libkernel32_a-ilockdec64.o intrincs/lib32_libkernel32_a-ilockexch.o intrincs/lib32_libkernel32_a-ilockexch64.o intrincs/lib32_libkernel32_a-ilockexchadd.o intrincs/lib32_libkernel32_a-ilockexchadd64.o intrincs/lib32_libkernel32_a-ilockexchptr.o intrincs/lib32_libkernel32_a-ilockinc.o intrincs/lib32_libkernel32_a-ilockinc16.o intrincs/lib32_libkernel32_a-ilockinc64.o intrincs/lib32_libkernel32_a-ilockor.o intrincs/lib32_libkernel32_a-ilockor64.o intrincs/lib32_libkernel32_a-ilockxor.o intrincs/lib32_libkernel32_a-ilockxor64.o intrincs/lib32_libkernel32_a-inbyte.o intrincs/lib32_libkernel32_a-inbytestring.o intrincs/lib32_libkernel32_a-indword.o intrincs/lib32_libkernel32_a-indwordstring.o intrincs/lib32_libkernel32_a-inword.o intrincs/lib32_libkernel32_a-inwordstring.o intrincs/lib32_libkernel32_a-outbyte.o intrincs/lib32_libkernel32_a-outbytestring.o intrincs/lib32_libkernel32_a-outdword.o intrincs/lib32_libkernel32_a-outdwordstring.o intrincs/lib32_libkernel32_a-outword.o intrincs/lib32_libkernel32_a-outwordstring.o intrincs/lib32_libkernel32_a-readcr0.o intrincs/lib32_libkernel32_a-readcr2.o intrincs/lib32_libkernel32_a-readcr3.o intrincs/lib32_libkernel32_a-readcr4.o intrincs/lib32_libkernel32_a-readmsr.o intrincs/lib32_libkernel32_a-writecr0.o intrincs/lib32_libkernel32_a-writecr2.o intrincs/lib32_libkernel32_a-writecr3.o intrincs/lib32_libkernel32_a-writecr4.o intrincs/lib32_libkernel32_a-writemsr.o intrincs/lib32_libkernel32_a-__int2c.o intrincs/lib32_libkernel32_a-RtlSecureZeroMemory.o intrincs/lib32_libkernel32_a-rdtsc.o intrincs/lib32_libkernel32_a-readfsbyte.o intrincs/lib32_libkernel32_a-readfsword.o intrincs/lib32_libkernel32_a-readfsdword.o intrincs/lib32_libkernel32_a-writefsbyte.o intrincs/lib32_libkernel32_a-writefsword.o intrincs/lib32_libkernel32_a-writefsdword.o Step 2 results in a broken archive whereas the step 1 result still looks ok from what I can see. Please find attached both files. libkernel32.a after step 1 and after step 2. P.S.: I have also included the result of the case that libkernel32.a is not present when running step 2 (namely step2b).
Both your step2 and step2b archives are truncated. The bug report as-is doesn't give us any easy way of reproducing a problem in ar, which means it is unlikely to be investigated further. If you package up the object files added in step2 we might be able to reproduce your problem.
Created attachment 14871 [details] input files for step2 Please find in libkernel32-input.tgz the input files for step 2 and let me know if/how I can help to solve this issue.
Unsurprisingly, ar compiled on a linux host (bith 32 and 64 bit) for a mingw target shows no problem handling this testcase, and I don't have a windows box with mingw installed to check for host specific ar bugs. One of the things that did change in binutils after 2.32 was the temporary file creation and renaming of the output file. Those changes may have exposed mingw bugs. Also, have you verified that running the ar commands by hand creates the same broken archives?
If you mean running the ar command on the console rather than letting makefile perform this task: yes, same result. Regarding the temporary file creation: I had trouble deleting a tmp like folder within the build tree. Windows asked me if I want to remove the shared network folder, but I don't remember creating such. Maybe related?
(In reply to Daniel Starke from comment #4) > If you mean running the ar command on the console rather than letting > makefile perform this task: yes, same result. Yes, that was what I meant. > Regarding the temporary file creation: I had trouble deleting a tmp like > folder within the build tree. Windows asked me if I want to remove the > shared network folder, but I don't remember creating such. Maybe related? Possibly. Does the problem reproduce on a local filesystem?
(In reply to Alan Modra from comment #5) > > Regarding the temporary file creation: I had trouble deleting a tmp like > > folder within the build tree. Windows asked me if I want to remove the > > shared network folder, but I don't remember creating such. Maybe related? > > Possibly. Does the problem reproduce on a local filesystem? Sorry for being misleading here. All steps have been performed on a local filesystem. However, it appears that a temporary _shared_ folder was created during this process. Windows complained about it when I tried to delete all intermediate build files.