Short version: Currently if the server is built with --with-llvm the -devel packages must depend on clang for PGXS to work, even though llvm is otherwise optional. This is a particular problem on older platforms where 3rd party LLVM may be required to build the server's llvmjit support. Work around by skipping the default .bc generation if no clang is found by PGXS, as if $(with_llvm) was false.
Detail: If PostgreSQL is configured with --with--lvm it writes with_llvm=yes into Makefile.global via AC_SUBST, along with the CLANG path and the path to the LLVM_TOOLSET if supplied. PGXS sets up a %.bc dependency for OBJS if it detects that the server was compiled with llvm support. If clang is not found at PGXS extension build-time the extension build will then fail, despite the user not having installed the postgresql11-llvmjit (or whatever) package and the extension not declaring any explicit LLVM dependency or requirement. Andres and others went to a great deal of effort to make it possible to separate PostgreSQL's LLVM support, so a server built with LLVM support doesn't actually have a runtime dependency on llvm unless the llvmjit module is loaded. This allows packagers to separate it out and avoid the need to declare an llvm dependency on the main server package. I've found that this falls down for -devel packages like those the PGDG Yum team produces. The problem arises when a container or VM is used to build the server and its Makefile.global etc. Then the -devel package containing Makefile.global and other PGXS bits are installed on a new machine that does not have llvm's clang. PGXS builds will fail when they attempt to generate bytecode, since they expect clang to be present at the path baked in to Makefile.global - but it's absent. I propose that per the attached patch PGXS should simply skip adding the automatic dependency for .bc files if clang cannot be found. Extensions may still choose to explicitly declare the rule in their own Makefile if they want to force bitcode generation. If we want to get fancier about it, we could instead split the llvm support out from Makefile.global into a Makefile.llvm or similar, which is then conditionally included by Makefile.global if it exists. Makefile.llvm would be packaged in a new postgresqlXX-llvmjit-devel package since distros get uppity if you put makefile fragments in runtime packages. This package would depend on llvm-toolset and clang. If you install postgresqlXX-devel but not postgresqlXX-llvmjit-devel you don't get bitcode and don't need clang. If you install postgresqlXX-llvmjit-devel, the same clang as we built the server with is declared as a dependency and Makefile.llvm is included, so it all works. But I don't think it's worth the hassle and I'd rather just skip automatic bitcode generation if we don't find clang. See also yum packagers report at https://www.postgresql.org/message-id/CAMsr+YHokx0rWLV561z3=gai6cm4yjekgclkqmdwqstejvy...@mail.gmail.com . -- Craig Ringer http://www.2ndQuadrant.com/ 2ndQuadrant - PostgreSQL Solutions for the Enterprise
diff --git a/src/Makefile.global.in b/src/Makefile.global.in index e3ea7f21a7..df191709b2 100644 --- a/src/Makefile.global.in +++ b/src/Makefile.global.in @@ -1020,6 +1020,21 @@ endif # enable_coverage # LLVM support # +# Don't try to build llvm bitcode if the clang used when Pg itself was built +# can no longer be found. This is possible when this Makefile.global is +# installed via a -devel package that doesn't have a hard dependency on clang, +# particularly for enterprise distros that may use a newer clang for builds. +ifeq ($(with_llvm),yes) +# Only override setting made by Makefile.global defaults not on cmdline etc +ifeq ($(origin with_llvm),file) +ifeq ($(wildcard $(CLANG)),) +$(warning disabling llvm bitcode generation: $$(CLANG) = $(CLANG) not found) +with_llvm = no +endif +endif +endif + ifndef COMPILE.c.bc # -Wno-ignored-attributes added so gnu_printf doesn't trigger # warnings, when the main binary is compiled with C.
