FS#77413 - [wine] Missing libunwind runtime dependency
Attached to Project:
Community Packages
Opened by Krzysztof Bogacki (Saancreed) - Monday, 06 February 2023, 21:02 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:07 GMT
Opened by Krzysztof Bogacki (Saancreed) - Monday, 06 February 2023, 21:02 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:07 GMT
|
Details
Description:
Wine cannot run even the simplest programs unless libunwind, which is not in wine's depends (not even transitively), is installed manually by the user. Additional info: * package version: wine=8.1-1 Steps to reproduce (in a clean chroot/container): # pacman -S wine mingw-w64-gcc $ echo 'int main() { return 0; }' > ./true.c $ x86_64-w64-mingw32-gcc -o ./true.exe ./true.c $ wine ./true.exe wine: could not load ntdll.so: libunwind.so.8: cannot open shared object file: No such file or directory 0024:err:environ:run_wineboot failed to start wineboot c00000e5 wine: could not load kernel32.dll, status c0000135 |
This task depends upon
Closed by Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:07 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/wine/issues/7
Saturday, 25 November 2023, 20:07 GMT
Reason for closing: Moved
Additional comments about closing: https://gitlab.archlinux.org/archlinux/p ackaging/packages/wine/issues/7
$ ldd /usr/lib/wine/x86_64-unix/ntdll.so
linux-vdso.so.1 (0x00007ffe3fb8f000)
libunwind.so.8 => not found
libc.so.6 => /usr/lib/libc.so.6 (0x00007f89f9071000)
/usr/lib64/ld-linux-x86-64.so.2 (0x00007f89f932a000)
"List all direct library dependencies."
https://wiki.archlinux.org/title/Arch_package_guidelines#Package_dependencies
This package does not conform to that rule, and it should.
The namcap tool also warns about these as issues.
Declaring the direct, link-level dependencies is the gold standard best practice,
maybe except in case of a very few of the lowest level libraries that virtually
everything depends on (like glibc / gcc-libs).
In the olden days, using transitive dependency resolution was generally the norm and encouraged by namcap, although each maintainer would use their own judgement. Over the last few years, they been explicitly discouraged with the namcap check being updated to throw a warning when package does not list its direct dependencies.
Wonder how we can get @felixonmars attention or help him in some way? A lot of wine bugs has been left unfixed for years - even trivial one-line fixes.