On Sun, Jun 20, 2021 at 11:01 PM Andres Freund <andres@anarazel.de> wrote:
> On 2021-06-19 10:12:03 -0400, Tom Lane wrote:
> > Is a compile-time conditional really going to be reliable? See nearby
> > arguments about compile-time vs run-time checks for libpq features.
> > It's not clear to me how tightly LLVM binds its headers and running
> > code.
>
> It should be fine (and if not we have plenty other places it'd be
> problematic). LLVM embeds the version between user of llvm and the
> library version in some symbol, so if there's a sufficient mismatch
> it'll cause link time issues. Of course that only works for major
> versions, but that shouldn't be an issue here.
I looked into this a bit. On the usual Unixoid server OSes the first
line of defence is that the major version is baked into the library
name to support parallel installation of major versions, so our
llvmjit.so is linked against eg libLLVM-13.so.1 (all controlled by
llvm-config), and then there are further defences like versioned
symbols, LLVM_13 etc on some platforms.
Curiously, they skip this scheme for Macs (see their AddLLVM.cmake
file) and Windows. So of course I wanted to try to see if I could
make it break in the way Tom imagined, on a Mac. There, I use
MacPorts, and it has separate packages for major versions, for example
"llvm-12", much like other distros. The package maintainers put
libLLVM.dylib (LLVM project's choice for this platform) into different
paths under .../libexec/llvm-$VERSION/.... (package maintainer's
choice), and there is a tool to select the current default (alarm
bells ringing at this point). The first observation is that the
Mach-O "compatibility version" is 1.0.0 on all the .dylibs, so yeah,
that mechanism isn't going to save you, but ... it turns out to be a
moot question for now because, to my surprise, we're statically
linking LLVM into our llvmjit.so on that platform. That turns out to
be because llvm-config --libs won't spit out dynamic link options if
it can't find a library name with the version embedded in it. I see
now that Brew's maintainers take it on themselves to create that
symlink[1] (unlike MacPorts'), so ... erm, could be trouble there, I
dunno because I don't want to install that, but if so, maybe they
asked for it? I guess that none of this stuff really matters for real
world non-hacker users, who are probably using an installer that ships
its own copy of the thing. I expect it'll be the same on Windows when
we eventually support LLVM there. /me closes Macintosh
[1] https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/llvm.rb#L175