Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
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 Toolybird (Toolybird) - Tuesday, 07 February 2023, 20:52 GMT
Opened by Krzysztof Bogacki (Saancreed) - Monday, 06 February 2023, 21:02 GMT
Last edited by Toolybird (Toolybird) - Tuesday, 07 February 2023, 20:52 GMT
|
DetailsDescription:
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
$ 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).