[Bug 1971901] Re: dlltool uses non-unique temp filenames
Bug Watch Updater
1971901 at bugs.launchpad.net
Sat May 21 08:14:26 UTC 2022
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
Foundations Bugs, 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
More information about the foundations-bugs
mailing list