libunwind: Causes other ports to fail to build

[opencoff (Sudhi Herle)]

xz on arm64 macbook pro (Monterey) fails to build.

configure:5920: checking whether the C compiler works
configure:5942: /usr/bin/clang -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch arm64 -arch x8
6_64 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_arch
ivers_xz/xz/work/xz-5.2.7/src/liblzma/check -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.
sdk -L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk 
-arch arm64 -arch x86_64 conftest.c  >&5
ld: in '/opt/local/lib/libunwind.dylib', building for macOS-x86_64 but attempting to link with file built for macOS-arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Is likely the culprit?

[opencoff (Sudhi Herle)]

config.log

[jmroot (Joshua Root)]

The libunwind port really needs to move to a separate prefix so things won't accidentally link with it like this.

[kencu (Ken)]

the libunwind port should not install anything on 10.7+

[kencu (Ken)]

that will break dozens of existing builds, but has to be done eventually

[nilason (Nicklas Larsson)]

I first experienced a crash of MacPort's and System's libunwind as reported with #68250.

It seems to me Xcode 15 brought changes that are causing this. With the libunwind port installed, building against libc++ the linker hooks up any binary to MacPorts' dylib making opportunistic linking for basically all C++ based ports. Something that will also cause crash in case of thrown exception. This was not the case pre-Xcode 15.

I tend to agree with Ken, to not install the port libunwind on 10.7+ (even though it is included in the system since 10.6: ​https://github.com/llvm/llvm-project/blob/main/libunwind/include/libunwind.h). I also believe this is quite an urgent matter, as most problems will likely appear only in runtime, for potentially any C++ based ports.

[nilason (Nicklas Larsson)]

To illustrate the automatic linking by Xcode 15's Clang to MacPorts' libunwind, if present:

cat << EOF > /tmp/test.cpp
#include <iostream>
int main() {
    std::cout << "Hello MacPorts!";
    return 0;
}
EOF

/usr/bin/clang++ --version
echo 'With LIBRARY_PATH set to $prefix/lib:'
LIBRARY_PATH='/opt/local/lib' /usr/bin/clang++ -dynamiclib -o /tmp/test.dylib  /tmp/test.cpp
/usr/bin/otool -L /tmp/test.dylib
echo "With LIBRARY_PATH **not** set:"
/usr/bin/clang++ -dynamiclib -o /tmp/test.dylib  /tmp/test.cpp
/usr/bin/otool -L /tmp/test.dylib

Will result in

Apple clang version 15.0.0 (clang-1500.0.40.1)
Target: x86_64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
With LIBRARY_PATH set to $prefix/lib:
test.dylib: 
	/tmp/test.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.151.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.0.0)
	/opt/local/lib/libunwind.1.dylib (compatibility version 1.0.0, current version 5.0.1)
With LIBRARY_PATH **not** set:
test.dylib: 
	/tmp/test.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.151.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.0.0)}}}

[nilason (Nicklas Larsson)]

In 5741e9657e2fced0b576b2adc4f2e5eb1282334f/macports-ports (master):

PDAL: enable use of system libunwind, drop dependency of port

This doesn't solve the problem with Xcode 15, automatically linking to
MacPorts' libunwind, but it makes it possible to some degree avoid
installing the port in the first place.

See #68250
See #66250

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #68609.

[barracuda156]

Replying to nilason:

I first experienced a crash of MacPort's and System's libunwind as reported with #68250.

It seems to me Xcode 15 brought changes that are causing this. With the libunwind port installed, building against libc++ the linker hooks up any binary to MacPorts' dylib making opportunistic linking for basically all C++ based ports. Something that will also cause crash in case of thrown exception. This was not the case pre-Xcode 15.

I tend to agree with Ken, to not install the port libunwind on 10.7+ (even though it is included in the system since 10.6: ​https://github.com/llvm/llvm-project/blob/main/libunwind/include/libunwind.h). I also believe this is quite an urgent matter, as most problems will likely appear only in runtime, for potentially any C++ based ports.

Yes, this is a problem on Sonoma, multiple ports opportunistically link to libunwind. Just one example: #68701 (but there are many more).

[kencu (Ken)]

see ​https://github.com/macports/macports-ports/pull/27319

[cooljeanius (Eric Gallager)]

I opened ​https://github.com/macports/macports-ports/pull/30477 due to this

[cooljeanius (Eric Gallager)]

In f9e46b43b68d978a7fe667ae74e49ad23238d7c0/macports-ports (master):

osxbom: switch to lib-style depspec for libunwind

See: #66250
Also revert to previous bin-style depspec for coreutils,
and remove dependency on libmacho-headers

[cooljeanius (Eric Gallager)]

Replying to barracuda156:

Replying to nilason:

I first experienced a crash of MacPort's and System's libunwind as reported with #68250.

It seems to me Xcode 15 brought changes that are causing this. With the libunwind port installed, building against libc++ the linker hooks up any binary to MacPorts' dylib making opportunistic linking for basically all C++ based ports. Something that will also cause crash in case of thrown exception. This was not the case pre-Xcode 15.

I tend to agree with Ken, to not install the port libunwind on 10.7+ (even though it is included in the system since 10.6: ​https://github.com/llvm/llvm-project/blob/main/libunwind/include/libunwind.h). I also believe this is quite an urgent matter, as most problems will likely appear only in runtime, for potentially any C++ based ports.

Yes, this is a problem on Sonoma, multiple ports opportunistically link to libunwind. Just one example: #68701 (but there are many more).

I think the most important one to focus on at this point is cmake, as that's required to build newer versions of llvm/clang, which a lot of other ports depend upon