Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 865637 - sys-libs/libunwind linked with sys-devel/gcc's libgcc_s breaks application built with app-emulation/wine-vanilla winegcc/wineg++
Summary: sys-libs/libunwind linked with sys-devel/gcc's libgcc_s breaks application bu...
Status: RESOLVED NEEDINFO
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-18 06:14 UTC by yshuiv7
Modified: 2023-02-03 06:35 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description yshuiv7 2022-08-18 06:14:25 UTC
This is complicated, and I don't know every bit of it yet.

The symptom is that when an application built with wineg++ throws and exception, it would just abort(), and the exception can't be catch or handle at all.

What's happening is that, application built this way depends on libgcc_s.so and libunwind.so at the same time. These two libraries have symbol with the same name, but ABI incompatible with each other. During exception throwing, a called is made from libgcc_s.so's _Unwind_RaiseException to libunwind.so's _Unwind_GetCFA, resulting in libgcc_s.so getting garbage CFA. It fails to find a exception handler and aborts.

I don't know how to solve this. It just look all wrong to me, I was surprised that nobody has caught this until now.

However, I noticed ArchLinux is doing _this_ [0]. And this indeed fixed the problem. The difference is that now libunwind.so isn't linked with libgcc_s.so anymore. ldd output comparison:

Before:
        linux-vdso.so.1 (0x00007fff90510000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f2a2afde000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f2a2b21b000)
        libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/libgcc_s.so.1 (0x00007f2a2afbe000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f2a2af9e000)

After:
        linux-vdso.so.1 (0x00007ffcc1af5000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f32c532e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f32c556b000)

Why does this make a difference? I don't know.

[0]: https://github.com/archlinux/svntogit-packages/blob/bd8ecd47e91dbb2cf77f82ca3a5a94ef1263eb31/trunk/PKGBUILD#L26


Reproducible: Always
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-01-03 06:53:02 UTC
It seems unlikely that sed would do it given we default to -Wl,--as-needed in LDFLAGS in profiles. I suppose it could happen if you override LDFLAGS in e.g. make.conf without using the profile definition too.

Please include emerge --info.
Comment 2 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-01-03 06:53:27 UTC
(In reply to Sam James from comment #1)
> It seems unlikely that sed would do it given we default to -Wl,--as-needed
> in LDFLAGS in profiles. I suppose it could happen if you override LDFLAGS in
> e.g. make.conf without using the profile definition too.
> 
> Please include emerge --info.

Also, while it sounds simple, a test program + needed commands to reproduce + full output would be useful, as someone who knows zilch about wine.
Comment 3 Ionen Wolkens gentoo-dev 2023-01-03 17:13:12 UTC
winegcc/g++ is usable like normal gcc (e.g. `winegcc -o hello hello.c`) except it creates hello.exe.so and hello.exe (latter is a shell script wrapper), and you can run it as `./hello.exe` or `wine hello.exe.so`.

Still need some code to reproduce with though.