Straighten out the libunwind confusion -- PR 27319
Fred Wright
fw at fwright.net
Mon Jan 20 02:13:20 UTC 2025
On Sun, 19 Jan 2025, Ken Cunningham wrote:
> I guess it's about time we addressed the issue with libunwind.
>
> libunwind is involved in stack traces and exception handling.
>
> it is a separate library on linux and on MacOSX < 10.7.
>
> As of 10.7, libunwind was rolled into libSystem.
No, Apple started providing it in 10.6 - see the headers and libSystem.
> Jeremy set up a libunwind port years ago to support older systems < 10.7.
>
> Unfortunately the (old) libunwind library and headers have been installed on all newer systems ever since.
>
> The libunwind installed by the libunwind port suits 10.6 and less just fine, but has no role being installed on 10.7+.
>
> A PR to have it not install anything (just be a dummy port exactly like libcxx is for libc++ is here:
>
> https://github.com/macports/macports-ports/pull/27319
I'd always assumed that libunwind interacts with the C++ stdlib in a way
that makes it necessary to use the MacPorts libunwind whenever the
cxx_stdlib selection mismatches the OS default (i.e., most 10.6-10.8 x86
systems).
> Once libunwind is a dummy port on 10.7, there will be breakage. Some things will be unbroken just by revbumping.
>
> Whether all the ports that enable stack unwinding, etc, are smart enough to know they should just use libSystem instead of libunwind on MacOS is unknown... probably, lots of them don't know to do that.
>
> There is a much newer libunwind currently installed with the clang ports. It would be similar to what is being used in modern MacOS systems.
>
> We could consider installing that into ${prefix} and let it be found, but that just seems like a bad idea to be doing that. Perhaps it could work out. It would satisfy builds that are looking for the libunwind library to enable stack unwinding.
>
> I would suggest we don't install that new libunwind into ${prefix}, we let libunwind be a dummy port and install nothing on 10.7+, and then start the project of fixing ports that benefit from the functionality of libunwind but don't know enough to use libSystem on newer MacOS -- that is what they should be doing anyway.
It should be in a different directory that can be accessed by opt-in.
> There will be wreckage from this.
Quite possibly.
Fred Wright
More information about the macports-dev
mailing list