On Sun, Jun 20, 2021 at 11:01 PM Andres Freund <and...@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
