On Thu, Mar 15, 2018 at 6:19 PM, Andres Freund <andres@anarazel.de> wrote:
> What we were talking about in this subthread was about a depency on
> clang, not LLVM. And that's just needed at buildtime, to generate the
> bitcode files (including synchronizing types / function signatures).
I was actually thinking of both the buildtime and runtime dependency
because I did not realize the PGDG packages already depend on EPEL.
> For the yum.pg.o, which already depends on EPEL, there's a new enough
> LLVM version. There's a new enough version in RHEL proper, but it
> appears to only be there for mesa (llvm-private).
Indeed RHEL 7 comes with llvm-private for mesa but that doesn't seem
kosher to use for other things.
When I said packagers I was only thinking of PGDG. I was thinking the
software collections would be the likely solution for the PGDG
packages for both buildtime and runtime. But it seems using clang from
software collections and LLVM from EPEL is also a possibility,
assuming that the newer clang generates IR that the older libraries
are guaranteed to be able to load.
For RHEL proper, I would guess that PG11 is too late for RHEL8 which,
according to history, should be coming soon.
For RHEL9 I would really expect RedHat to add llvm and clang to proper
RHEL and build/run against those, even if they add it only for
Postgres (like they did for mesa). I really don't see them shipping
without a major speedup for a major DB, also because in the meantime
the JIT in PG will have matured. That's also why I find it important
to support gcc and not restrict JIT to clang builds as I expect that
RedHat and all other Linux distros want to build everything with gcc
and asking them to switch to clang or give up JIT will put them in a
hard spot. As far as I know clang does promise gcc compatibility in
the sense that one can link together .o files compiled with both so I
expect the combination not to cause issues (assuming the other
compiler flags affecting binary compatibility are aligned).
