Launchpad has imported 16 comments from the remote bug at https://bugs.winehq.org/show_bug.cgi?id=52770.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2022-04-04T17:19:02+00:00 Bernhard Rosenkraenzer wrote: Building wine 7.5 (with wine-staging patches, but they shouldn't be relevant to this) with "make -j64" fails with tools/winebuild/winebuild -b x86_64-w64-mingw32 -w --implib -o dlls/rpcrt4/librpcrt4.delay.a --export \ /home/bero/abf/wine/BUILD/wine-7.5/dlls/rpcrt4/rpcrt4.spec /usr/bin/x86_64-w64-mingw32-dlltool: bfd_open failed reopen stub file: rpcrt4_dll_s00176.o: No such file or directory winebuild: /usr/bin/x86_64-w64-mingw32-dlltool failed with status 1 make: *** [Makefile:297034: dlls/rpcrt4/librpcrt4.delay.a] Error 1 Probably the library is assembled before all object files belonging to it are built. Building with make (without SMP) works. Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/11 ------------------------------------------------------------------------ On 2022-04-04T19:28:51+00:00 Cybermax wrote: Is there a change if you build with lesser threads? Eg. make -j8 or something assuming you have a threadripper with 32 cores/64 threads? And possibly also interesting - distro, gcc and mingw-w64 version. Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/12 ------------------------------------------------------------------------ On 2022-04-04T19:36:49+00:00 Alexandre Julliard wrote: These objects file are not created from the makefile. It sounds more like it's running into some kind of resource limit. Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/13 ------------------------------------------------------------------------ On 2022-04-04T19:50:11+00:00 Cybermax wrote: (In reply to Alexandre Julliard from comment #2) > These objects file are not created from the makefile. It sounds more like > it's running into some kind of resource limit. tmpfs maybe? Just wondering since i got that exact error when building wine on OBS.. Also got a couple of other very strange errors that failed building on OBS with files that was not found, but could not find a error message from the actual compile.. Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/14 ------------------------------------------------------------------------ On 2022-04-08T13:04:47+00:00 Eric-pouech wrote: I've run into a similar issue looking at the compile traces lets me believe that the issue arises when two instances of mingw dlltool run at the same time, and thrashing each other temporary files indeed, this ugly hack lets the compilation succeeds (it was failing almost always; sometimes on a different DLL) ----------- diff --git a/tools/winebuild/import.c b/tools/winebuild/import.c index c876d51f8e6..8049530a7e5 100644 --- a/tools/winebuild/import.c +++ b/tools/winebuild/import.c @@ -1595,7 +1595,11 @@ static void build_windows_import_lib( const char *lib_na> strarray_add( &args, lib_name ); strarray_add( &args, "-d" ); strarray_add( &args, def_file ); - + strarray_add( &args, "-t" ); + { + char tmp[128]; sprintf(tmp, "%u\n", getpid()); + strarray_add( &args, tmp ); + } switch (target.cpu) { case CPU_i386: ---------- Bernhard, can you test this on your side? I don't see a simple way to fix it... Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/15 ------------------------------------------------------------------------ On 2022-04-08T15:03:19+00:00 Eric-pouech wrote: hmmm thinking about it, doesn't look quite right (or sufficient) in the dlltool source code, if no -t prefix is given, will generate its own prefix based on pid... need more investigation Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/16 ------------------------------------------------------------------------ On 2022-04-08T15:31:06+00:00 Eric-pouech wrote: I'm testing on two environments: E1) with dlltool 2.38-1 E2) with dlltool 2.37-3 I see the error in E1 only <g> on all env, I run > strace winebuild... <c/l from makefile> -v -v >& log > grep exec log results: ==================== E2) pid 12272] execve("/usr/bin/x86_64-w64-mingw32-dlltool", ["/usr/bin/x86_64-w64-mingw32-dllt"..., "-k", "-y", "dlls/iphlpapi/libiphlpapi.delay."..., "-d", "libiphlpapi.delay-625082dd.def", "-m", "i386:x86-64", "--as-flags=--64"], 0x7ffc19487b48 /* 56 vars */) = 0 [pid 12273] execve("/usr/bin/x86_64-w64-mingw32-as", ["/usr/bin/x86_64-w64-mingw32-as", "--64", "-o", "daesh.o", "daesh.s"], 0x7fffa1e12cf8 /* 56 vars */ <unfinished ...> [pid 12273] <... execve resumed>) = 0 [pid 12274] execve("/usr/bin/x86_64-w64-mingw32-as", ["/usr/bin/x86_64-w64-mingw32-as", "--64", "-o", "daest.o", "daest.s"], 0x7fffa1e12cf8 /* 56 vars */ <unfinished ...> [pid 12274] <... execve resumed>) = 0 ==================== E1-without the patch below) execve("tools/winebuild/winebuild", ["tools/winebuild/winebuild", "-b", "x86_64-w64-mingw32", "-w", "--implib", "-o", "dlls/iphlpapi/libiphlpapi.delay."..., "--export", "/home/eric/wine/wine/dlls/iphlpa"..., "-v", "-v"], 0x7ffc4d598b28 /* 54 vars */) = 0 [pid 9078] execve("/usr/bin/x86_64-w64-mingw32-dlltool", ["/usr/bin/x86_64-w64-mingw32-dllt"..., "-k", "-y", "dlls/iphlpapi/libiphlpapi.delay."..., "-d", "libiphlpapi.delay-6250734a.def", "-m", "i386:x86-64", "--as-flags=--64"], 0x7ffd66663948 /* 54 vars */) = 0 [pid 9079] execve("/usr/bin/x86_64-w64-mingw32-as", ["/usr/bin/x86_64-w64-mingw32-as", "--64", "-o", "iphlpapi_dll_h.o", "iphlpapi_dll_h.s"], 0x7ffd4c406e08 /* 54 vars */ <unfinished ...> [pid 9079] <... execve resumed>) = 0 [pid 9080] execve("/usr/bin/x86_64-w64-mingw32-as", ["/usr/bin/x86_64-w64-mingw32-as", "--64", "-o", "iphlpapi_dll_t.o", "iphlpapi_dll_t.s"], 0x7ffd4c406e08 /* 54 vars */ <unfinished ...> [pid 9080] <... execve resumed>) = 0 ==================== E1-with the patch above) execve("tools/winebuild/winebuild", ["tools/winebuild/winebuild", "-b", "x86_64-w64-mingw32", "-w", "--implib", "-o", "dlls/iphlpapi/libiphlpapi.delay."..., "--export", "/home/eric/wine/wine/dlls/iphlpa"..., "-v", "-v"], 0x7ffd5925c228 /* 54 vars */) = 0 [pid 9601] execve("/usr/bin/x86_64-w64-mingw32-dlltool", ["/usr/bin/x86_64-w64-mingw32-dllt"..., "-k", "-y", "dlls/iphlpapi/libiphlpapi.delay."..., "-d", "libiphlpapi.delay-6250774f.def", "-t", "9600\n", "-m", "i386:x86-64", "--as-flags=--64"], 0x7fff84ee6468 /* 54 vars */) = 0 [pid 9602] execve("/usr/bin/x86_64-w64-mingw32-as", ["/usr/bin/x86_64-w64-mingw32-as", "--64", "-o", "9600\nh.o", "9600\nh.s"], 0x7ffdc7cf0c98 /* 54 vars */ <unfinished ...> [pid 9602] <... execve resumed>) = 0 [pid 9603] execve("/usr/bin/x86_64-w64-mingw32-as", ["/usr/bin/x86_64-w64-mingw32-as", "--64", "-o", "9600\nt.o", "9600\nt.s"], 0x7ffdc7cf0c98 /* 54 vars */ <unfinished ...> [pid 9603] <... execve resumed>) = 0 to summarize, binutils 2.38 no longer generates a temp file name dependant on the pid... using the -t options forces back the regular behavior... Bernhard, Sveinar: could you also look at the dlltool --version output to see if this converges to 2.38* looks I have to dig further into binutils source code Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/17 ------------------------------------------------------------------------ On 2022-04-08T15:35:56+00:00 Eric-pouech wrote: https://sourceware.org/bugzilla/show_bug.cgi?id=28885 so it's a known issue in 2.38 and fixed in 2.39 backport to 2.38 to be checked Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/18 ------------------------------------------------------------------------ On 2022-04-08T19:57:03+00:00 Cybermax wrote: (In reply to Eric Pouech from comment #7) > https://sourceware.org/bugzilla/show_bug.cgi?id=28885 > > so it's a known issue in 2.38 and fixed in 2.39 > backport to 2.38 to be checked So, this seems to be the patch then? https://sourceware.org/git/?p=binutils- gdb.git;a=patch;h=99852365513266afdd793289813e8e565186c9e6 binutils-38 for jammy was updated 23/3-22, but could not find anything in the debian patches nor the changelog for this. Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/19 ------------------------------------------------------------------------ On 2022-04-09T08:50:50+00:00 Eric-pouech wrote: > binutils-38 for jammy was updated 23/3-22, but could not find anything in > the debian patches nor the changelog for this. that's what I meant with "backport to 2.38 to be checked"... not sure <put here your favorite distro> will post an update for this change Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/20 ------------------------------------------------------------------------ On 2022-04-11T07:20:29+00:00 Eric-pouech wrote: (In reply to Eric Pouech from comment #9) > > binutils-38 for jammy was updated 23/3-22, but could not find anything in > > the debian patches nor the changelog for this. > that's what I meant with "backport to 2.38 to be checked"... not sure <put > here your favorite distro> will post an update for this change and to be precise, one should check the binutils version on which mingw's dlltool is built upon (not the binutils version for the ELF compilation, which may be on a different version) x86_64-w64-mingw32-dlltool --version i686-w64-mingw32-dlltool --version Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/21 ------------------------------------------------------------------------ On 2022-04-14T14:36:38+00:00 Lorenzofer wrote: I can confirm that recompiling mingw-binutils witht his patch https://sourceware.org/git/?p=binutils-gdb.git;a=patch;h=99852365513266afdd793289813e8e565186c9e6 fix the issue Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/22 ------------------------------------------------------------------------ On 2022-05-16T17:09:53+00:00 Ztirfe Elgnid wrote: *** Bug 53011 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/25 ------------------------------------------------------------------------ On 2022-05-16T17:11:01+00:00 Ztirfe Elgnid wrote: Resolving upstream. Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/26 ------------------------------------------------------------------------ On 2022-05-21T01:06:15+00:00 Dimesio wrote: *** Bug 53024 has been marked as a duplicate of this bug. *** Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/28 ------------------------------------------------------------------------ On 2022-05-21T01:21:01+00:00 Dimesio wrote: I just ran into this trying to build wine-devel-7.9 packages for jammy. The Ubuntu bug is https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901. Reply at: https://bugs.launchpad.net/ubuntu/+source/binutils- mingw-w64/+bug/1971901/comments/29 ** Changed in: wine Status: Unknown => Won't Fix ** Changed in: wine Importance: Unknown => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to binutils in Ubuntu. https://bugs.launchpad.net/bugs/1971901 Title: dlltool uses non-unique temp filenames Status in binutils: Fix Released Status in Wine: Won't Fix Status in binutils package in Ubuntu: New Status in binutils-mingw-w64 package in Ubuntu: New Bug description: Description: Ubuntu 22.04 LTS Release: 22.04 binutils-mingw-w64-x86-64 2.38-3ubuntu1+9build1 /usr/bin/x86_64-w64-mingw32-dlltool now encounters errors like tools/winebuild/winebuild -b x86_64-w64-mingw32 -w --implib -o dlls/winmm/libwinmm.delay.a --export \ ../wine-6.0.4/dlls/winmm/winmm.spec Assembler messages: Error: can't open winmm_dll_t.s for reading: No such file or directory /usr/bin/x86_64-w64-mingw32-dlltool: /usr/bin/x86_64-w64-mingw32-as exited with status 1 /usr/bin/x86_64-w64-mingw32-dlltool: failed to open temporary tail file: winmm_dll_t.o: No such file or directory winebuild: /usr/bin/x86_64-w64-mingw32-dlltool failed with status 1 make: *** [Makefile:195227: dlls/winmm/libwinmm.delay.a] Error 1 make: *** Waiting for unfinished jobs.... tools/winebuild/winebuild -b x86_64-w64-mingw32 -w --implib -o dlls/winmm/libwinmm.cross.a --export \ ../wine-6.0.4/dlls/winmm/winmm.spec Due to dlltool using names like winmm_dll_t.s and winmm_dll_t.o for it's temp file - these are not unique when building libwinmm.delay.a and libwinmm.cross.a in parallel. (This can of course affect any dll wine is building import libs for, winmm is just the one I happaned to get caught on). This is regression newly introduced in binutils 2.38 vs older versions which used getpid() as the basis of their temp name. We just encountered it as part of updating our CI for a winelib application from focal to jammy, but it seems to have been discovered by others already: see https://sourceware.org/bugzilla/show_bug.cgi?id=28885 There is an upstream fix on master (2.39) which is already backported to the binutils-2_38 branch: https://sourceware.org/git/gitweb.cgi?p=binutils- gdb.git;h=99852365513266afdd793289813e8e565186c9e6, so it should just be a matter of cherry-picking. Hopefully the fact it's a regression from impish->jammy and that upstream already backported it to 2.38 might make this a candidate for jammy-updates? To manage notifications about this bug go to: https://bugs.launchpad.net/binutils/+bug/1971901/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
