On Thu, Mar 15, 2018 at 6:19 PM, Andres Freund <and...@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).
