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

[Kevin Puetz]

Looks like https://launchpad.net/ubuntu/+source/binutils/2.38-4ubuntu2
is now in the ubuntu-proposed pocket (thanks Matthias!). So binutils-
mingw-w64 would just need a recompile based on that resulting new
binutils-source_2.38-4ubuntu2_all.deb.

I don't think there should be any changes needed to binutils-mingw-w64,
since it just has Build-Depends: binutils-source (>= 2.36~) it should
pick up the latest.

Any chance we could get binutils-mingw-w64 uploaded into
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/ppa so it
would rebuild with the new binutils-source package there? I'd be happy
to test that and confirm the fix (I'm quite confident it will fix this,
since I already made a local build some time back cherry-picking the
PR28885 patch and it worked).

-- 
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:
  Confirmed
Status in binutils-mingw-w64 package in Ubuntu:
  Confirmed

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