[Touch-packages] [Bug 1971901] Re: dlltool uses non-unique temp filenames
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 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: 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 -- 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
[Touch-packages] [Bug 1971901] Re: dlltool uses non-unique temp filenames
** Changed in: binutils (Ubuntu Jammy) Status: Fix Committed => Fix Released -- 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: 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 -- 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
[Touch-packages] [Bug 1971901] Re: dlltool uses non-unique temp filenames
binutils fix publised to jammy-updates on 2022-10-24, binutils-mingw-w64 would just need a recompile against binutils-source 2.38-4ubuntu2 to fix this issue. -- 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: Fix Released Status in binutils-mingw-w64 package in Ubuntu: Triaged Status in binutils source package in Jammy: Fix Committed 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 -- 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
[Touch-packages] [Bug 1971474] Re: SRU: Update gdb to the final 12.1 release in 22.04 LTS
> And it fixes a VSCode integration issue. Also Qt Creator. And probably most any other gdb GUI that displays a "locals" window and therefore might try to display an optimized-out symbol. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1971474 Title: SRU: Update gdb to the final 12.1 release in 22.04 LTS Status in gdb package in Ubuntu: Invalid Status in gdb source package in Jammy: Fix Committed Bug description: Update gdb to the final 12.1 release in 22.04 LTS. jammy ships with the gdb 12.1 release candidate, taken from the gdb-12 branch. Changes up to the final release are: - updated gnulib library - Fix for PR mi/29002 (Windows only) - gdb: fix 'remote show FOO-packet' aliases - various testsuite fixes - fixing compiler warnings - Fix bug in Ada number lexing - Remove "Ada Settings" node from the manual - Handle TLS variable lookups when using separate debug files. - PR 28980: gdb: don't copy entirely optimized out values in value_copy - gdb/mi: fix use after free of frame_info causing spurious notifications Comparing the test results between the two builds doesn't show any regression on any architecture. Also tested with a test rebuild of main, see LP: #1970233. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1971474/+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
[Touch-packages] [Bug 1971901] Re: dlltool uses non-unique temp filenames
> Changed in binutils-mingw-w64 (Ubuntu): > status: Triaged → Fix Released not fixed in Kinetic yet either; it would be if rebuilt with the binutils-source there now, but https://launchpad.net/ubuntu/+source/binutils-mingw-w64/9build1 built on 2022-04-26 is before Mattias brought in PR2885 on https://launchpad.net/ubuntu/+source/binutils/2.38-4ubuntu1 Unless you marked binutils-mingw-w64 as Fix Released in based on something I didn't find... -- 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: Fix Released Status in binutils-mingw-w64 package in Ubuntu: Fix Released Status in binutils source package in Jammy: Fix Committed 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 -- 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
[Touch-packages] [Bug 1971901] Re: dlltool uses non-unique temp filenames
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 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: 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 -- 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
[Touch-packages] [Bug 1971901] Re: dlltool uses non-unique temp filenames
It's fixed upstream on the 2.38 branch too, and kinetic has that update in binutils-source_2.38-4ubuntu1. So binutils-mingw-w64 just needs to be recompiled against that latest binutils-source package (no other changes needed, it already pulls the latest). And ideally an SRU back to jammy LTS, just as upstream backported it to 2.38. But I'm not someone who can actually make that upload... -- 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: 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 -- 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
[Touch-packages] [Bug 1971409] Re: value_copy: Assertion `arg->contents != nullptr' failed.
Looks like the specific upstream issue is https://github.deere.com/FOCUS/WineATL/blob/fab575865d1bbceedde12226d2517d17b20189bc/gdb/wine- add-symbol-file.py And there's a build for kinetic that contains the fix, which does actually install and work on jammy (since no other dependencies changed too much, at least not yet): https://github.com/microsoft/vscode- cpptools/issues/103#issuecomment-1151217772 ** Bug watch added: github.com/microsoft/vscode-cpptools/issues #103 https://github.com/microsoft/vscode-cpptools/issues/103 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to gdb in Ubuntu. https://bugs.launchpad.net/bugs/1971409 Title: value_copy: Assertion `arg->contents != nullptr' failed. Status in gdb package in Ubuntu: Confirmed Bug description: When debugging RP2040 with vscode this assert makes gdb crash. This is a new assert, that wasn't present in gdb 11. The fix is easy, replace `if (!value_lazy (val))` to `if (!value_lazy (val) && arg->contents != nullptr) `. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1971409/+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
[Touch-packages] [Bug 1971901] Re: dlltool uses non-unique temp filenames
** Also affects: wine via https://bugs.winehq.org/show_bug.cgi?id=52770 Importance: Unknown Status: Unknown -- 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: Unknown Status in Wine: Unknown 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
[Touch-packages] [Bug 1971901] Re: dlltool uses non-unique temp filenames
Linking binutils package and subscribing Mattias Klose since https://launchpad.net/ubuntu/+source/binutils/2.38-4ubuntu1 mentions "Update from the binutils 2.38 branch: Fix PR 28885" and so a rebuild based on binutils-source_2.38-4ubuntu1 would fix this issue. -- 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: Unknown 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
[Touch-packages] [Bug 1971901] Re: dlltool uses non-unique temp filenames
** Bug watch added: Sourceware.org Bugzilla #28885 https://sourceware.org/bugzilla/show_bug.cgi?id=28885 ** Also affects: binutils via https://sourceware.org/bugzilla/show_bug.cgi?id=28885 Importance: Unknown Status: Unknown ** Also affects: binutils (Ubuntu) Importance: Undecided Status: New -- 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: Unknown 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
[Touch-packages] [Bug 1848200] Re: gdb not stopping on breakpoint in a 32-bit program
@dannf Thanks, it works for on my x86 winelib program too (amd64
installation).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gdb in Ubuntu.
https://bugs.launchpad.net/bugs/1848200
Title:
gdb not stopping on breakpoint in a 32-bit program
Status in gdb package in Ubuntu:
Invalid
Status in gdb source package in Bionic:
In Progress
Status in gdb source package in Disco:
Invalid
Status in gdb source package in Eoan:
Invalid
Status in gdb source package in Focal:
Invalid
Bug description:
[Impact]
After upgrading gdb from 8.1-0ubuntu3 to 8.1-0ubuntu3.1, gdb does not stop
on breakpoint when running a 32-bit application (on 64-bit Ubuntu).
[Test Case]
This can be reproduced with a simple “hello world” program:
$ cat hello.c
#include
int main()
{
// printf() displays the string inside quotation
printf("Hello, World!");
return 0;
}
$ gcc -ggdb -m32 hello.c
$ gdb a.out
(gdb) b hello.c:5
Breakpoint 1 at 0x536: file hello.c, line 5.
(gdb) run
Starting program: /home/user/sandbox/a.out
warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xf7fd9be0.
warning: Breakpoint address adjusted from 0xf7fda195 to 0xf7fda195.
warning: Breakpoint address adjusted from 0xf7fdbd1c to 0xf7fdbd1c.
warning: Breakpoint address adjusted from 0xf7fdb924 to 0xf7fdb924.
warning: Breakpoint address adjusted from 0xf7fe99b3 to 0xf7fe99b3.
warning: Breakpoint address adjusted from 0xf7fea401 to 0xf7fea401.
warning: Breakpoint address adjusted from 0xf7fea706 to 0xf7fea706.
--- (and not stopping nor outputting the text…) ---
[Regression Risk]
Test case ran on arm64 and regression tested using the above test case on
amd64, i386 and s390x.
This regression was fixed on the upstream gdb-8.1 branch within a few
weeks of the breakage back in May 2018. Since then there have been no
other fixes in this area on that branch, implying this fixed the issue
and there were no further regressions discovered.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200/+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
