llvm-19 @19.1.1: possibly rpath-related problems on macOS Sequoia

[tglsfdc (Tom Lane)]

I'm having difficulty building postgresql with LLVM support (configure option --with-llvm) on Sequoia + Xcode 16.0, though it worked fine on previous macOS versions. Problem number one is a weird linker warning at build time:

ccache clang -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Werror=unguarded-availability-new -Wendif-labels -Wmissing-format-attribute -Wcast-function-type -Wformat-security -Wmissing-variable-declarations -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-unused-command-line-argument -Wno-compound-token-split-by-macro -Wno-format-truncation -Wno-cast-function-type-strict -g -O2 ...lots-of-.o-files-here... -L../../src/port -L../../src/common -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.0.sdk  -L/opt/local/libexec/llvm-19/lib  -Wl,-dead_strip_dylibs   -Wl,-export_dynamic -lz -lm -L/opt/local/lib -licui18n -licuuc -licudata -o postgres

ld: warning: reexported library with install name '@rpath/libunwind.1.dylib' found at '/opt/local/libexec/llvm-19/lib/libunwind.1.0.dylib' couldn't be matched with any parent library and will be linked directly

This is weird because so far as I can see, there's no reason for that library to be pulled into this link. There's no -lunwind in the command, nor do we use any of the APIs exported by that library. (We do use backtrace() and backtrace_symbols(), if that's relevant.) For that matter, the core server executable doesn't reference any LLVM stuff at all; all of that is in a separate loadable library that is not what this command is building. I've verified that removing -L/opt/local/libexec/llvm-19/lib from this link command silences the warning, but what's causing it?

Problem number two is that the built LLVM library fails at runtime, with

ERROR:  could not load library "/Users/tgl/pgsql/lib/postgresql/llvmjit.dylib": dlopen(/Users/tgl/pgsql/lib/postgresql/llvmjit.dylib, 0x000A): Library not loaded: @rpath/libLLVM.dylib
          Referenced from: <554524D2-EA18-38B0-9475-F9275F1A2822> /Users/tgl/pgsql/lib/postgresql/llvmjit.dylib
          Reason: no LC_RPATH's found

I gathered from some other tickets that the reason for this is a lack of a linker -rpath switch, and indeed if I add -Wl,-rpath,/opt/local/libexec/llvm-19/lib to the LDFLAGS then this problem goes away. However, I argue that this is LLVM's fault not postgresql's fault, because (a) llvm-config --ldflags mentions no such requirement, and (b) this all worked fine without that before Sequoia.

This is not specific to llvm-19; I get the same results with llvm-18. I've tried building with both the Apple-supplied clang and clang from MacPorts, no difference.

[tglsfdc (Tom Lane)]

Forgot to mention that adding -Wl,-rpath,... does not silence the whining about libunwind, which makes that even odder.

[ryandesign (Ryan Carsten Schmidt)]

We've discussed elsewhere (I can't find it right now) that using a MacPorts llvm will pull in its copy of libc++ instead of the system's (due to the -L flag you mentioned) and that this is undesirable. Your experience with its copy of libunwind is probably the same. libc++ and libunwind are both system libraries and in most cases we probably want to use those, not other versions of them installed by MacPorts. MacPorts also has a libunwind port and just having it installed causes lots of other software to fail to build because it supersedes the system copy of libunwind; see #66250.

[cjones051073 (Chris Jones)]

The issue with the llvm port versions of libc++ have been addressed for a while now. See e.g.

[a1d4865220b53c446adbcb4856f80f46029e2e8d/macports-ports]

Llvm 19 had that from the get go so never suffered from it.

Perhaps something similar should be consider for libunwind…

[kencu (Ken)]

Homebrew just last week spun the libunwind that is built with LLVM into a subdir, exactly as we just did with libc++, to avoid opportunistic linking:

​https://github.com/Homebrew/homebrew-core/commit/c2b0a53df5735b2433942ec504d4fb2abcdcbf2a

The current libunwind port in MacPorts needs to be modified to install it's software only on 10.6 and less, and be a no-op dummy port on newer systems. I would have done this already, but a ton of things will break and have to be revbumped and I wasn't sure we were quite up for that project yet. But we might as well be, as it will have to be done anyway.

There is a ticket somewhere to install the current libunwind port into a subdir, but this will break many things on 10.6 and less and seems needless to me now that a current libunwind is coming in with clang-N installation.

[cjones051073 (Chris Jones)]

b.t.w. ifs you think there is a bug with the information return by llvm-config, thats an issue for upstream LLVm so please report it there. Its not something we control on the MacPorts side.

[kencu (Ken)]

By the way, the reason this shows up only now is it appears libunwind only just started being installed along with the clang-18 port (or newer).

[tglsfdc (Tom Lane)]

To clarify, I do not have the libunwind port installed on the machine I'm seeing this on.

[cjones051073 (Chris Jones)]

The libunwind port is not the problem here. It's the version as Ken says that clang-18 and newer is now including. I think the fix is to do what home-brew does and configure the build to put this in a hidden sub-directory.

[tglsfdc (Tom Lane)]

OK, so I've now installed llvm-17 on my Sequoia machine ... and it works without either of the problems I mentioned. So this is not a "new with Sequoia" issue, it's a "new with llvm-18" issue. (llvm-17 is what I'd been using with Sonoma, too.) Apologies for stating the problem incorrectly to start with.

It seems like we (you) understand the libunwind glitch, but it's still not apparent to me why llvm-18 needs rpath hackery to load libLLVM.dylib when llvm-17 did not.

[Chris Jones <jonesc@…>]

In d5e732dc1463c6bcac16642b938585098f0dac0d/macports-ports (master):

clang-{18,19}: Move libunwind to sub-dir to avoid accidental linkage
See: #71052

[cjones051073 (Chris Jones)]

The above moves libunwind to a 'hidden' sub-folder.

This might also fix your rpath issue, I am not sure. As you did not upload a complete configure and build log for the issue you have its hard to say ...

[cjones051073 (Chris Jones)]

tglsfdc please report back here if the latest changes fix things for you ?

[tglsfdc (Tom Lane)]

Sorry for slow response. I can confirm that the link warnings about libunwind are gone with llvm-19 @19.1.1_0. However, I still get the "could not load library" failure when trying to invoke libLLVM, if I don't manually include an -rpath option. I don't understand why that is, since llvm-17 works fine without it, and the two libraries look about the same with "otool -L" or "otool -l". The detail about "Reason: no LC_RPATH's found" doesn't seem right, because according to "otool -L" both libraries have such a load command.

[ryandesign (Ryan Carsten Schmidt)]

Replying to kencu:

but a ton of things will break and have to be revbumped

Really? It looks like just a handful of ports:

% port echo depends:':libunwind($|\s)'
edencommon                      
fizz                            
folly                           
mvfst                           
osxbom                          
rspamd                          
rust-bootstrap-10.5             

There is a ticket somewhere to install the current libunwind port into a subdir,

#66250. I mentioned it in comment:2.

but this will break many things on 10.6 and less

Are you referring to ports that use the rust or cargo_fetch portgroups? I see that those use libunwind when the deployment target is less than 10.6.