Community Packages

Please read this before reporting a bug:

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

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/ (0x00007ffe3fb8f000) => not found => /usr/lib/ (0x00007f89f9071000)
/usr/lib64/ (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.