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
Task Type Bug Report
Category Packages: Multilib
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No



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
Comment by Krzysztof Bogacki (Saancreed) - Monday, 06 February 2023, 21:06 GMT
Unsurprisingly, the required library is mentioned by ldd:

$ 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)
Comment by Toolybird (Toolybird) - Tuesday, 07 February 2023, 20:52 GMT
libunwind is generally pulled in by mesa/xorg-server.
Comment by Michel (xantares) - Sunday, 16 April 2023, 11:56 GMT
yes, but its not unstalled in a chroot (its only pulled via makedepend)
Comment by Marcell Meszaros (MarsSeed) - Tuesday, 13 June 2023, 15:22 GMT
Arch wiki guideline aptly says:

"List all direct library 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).
Comment by Emil (xexaxo) - Saturday, 19 August 2023, 13:33 GMT
Story time:

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.