[Bug 1971901] Re: dlltool uses non-unique temp filenames

[Kevin Puetz]

The versioning is confusing because this package is not self-contiained.
It gets most of its source code from another package, recorded via
`Built-Using: binutils` in its debian/control file. The actual buggy
code is in binutils-source 2.38-3ubuntu1; binutils-source 2.38-4ubuntu2
contains the fix. This is the part of the status I updated to "Fix
Released".

binutils-mingw-w64 9build1 doesn't need any source changes, but the
current binary package is 2.38-3ubuntu1+9build1, which has the bugs
binutils 2.38-3ubuntu1 did. If one takes that binutils-
mingw-w64_9build1.dsc, as-is, and runs it through `pbuilder build ...`
in a basetgz that has jammy-updates enabled, its Build-Depends:
binutils-source (>= 2.36~) now picks 2.38-4ubuntu2 and produces
binutils-mingw-w64 2.38-4ubuntu2+9build1, which is a working binary
package. I have tested this locally, but I don't have any ubuntu project
permissions to get that uploaded anywhere official.

Hence the binutils the binutils-mingw-w64 is still just "triaged" (and,
as you saw, doesn't work). kinetic and lunar currently have the same
(broken) binary package too.

-- 
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:
  Fix Released
Status in binutils-mingw-w64 package in Ubuntu:
  Triaged
Status in binutils source package in Jammy:
  Fix Released
Status in binutils-mingw-w64 source package in Jammy:
  Triaged

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