Re: Header checking failures on LLVM-less machines - Mailing list pgsql-hackers

On 2019-01-28 19:51:22 -0500, Tom Lane wrote:
> On 2019-01-28 11:19:21 -0500, Tom Lane wrote:
> > Since the LLVM stuff went in, src/tools/pginclude/cpluspluscheck
> > fails on my main devel machine, because
> > 
> > In file included from /tmp/cpluspluscheck.jobsM6/test.cpp:3:
> > ./src/include/jit/llvmjit_emit.h:13:25: error: llvm-c/Core.h: No such file or directory
> > 
> > and then there's a bunch of ensuing spewage due to missing typedefs
> > etc.  llvmjit.h has the same problem plus this additional pointless
> > aggravation:
> > 
> > In file included from /tmp/cpluspluscheck.jobsM6/test.cpp:3:
> > ./src/include/jit/llvmjit.h:15:2: error: #error "llvmjit.h should only be included by code dealing with llvm"
> > 
> > I propose that we should fix this by making the whole bodies of those
> > two headers be #ifdef USE_LLVM.

Hm, I think it's sufficient that we error out if llvm was configured,
we've sufficient buildfarm machines running with it enabled.


> Actually, it also fails on another machine that does have LLVM installed:
> 
> In file included from /tmp/cpluspluscheck.LqnoZj/test.cpp:3:
> ./src/include/jit/llvmjit_emit.h: In function 'LLVMOpaqueValue* l_ptr_const(void*, LLVMTypeRef)':
> ./src/include/jit/llvmjit_emit.h:22:32: error: 'TypeSizeT' was not declared in this scope
>   LLVMValueRef c = LLVMConstInt(TypeSizeT, (uintptr_t) ptr, false);
>                                 ^~~~~~~~~
> ./src/include/jit/llvmjit_emit.h: In function 'LLVMOpaqueValue* l_sizet_const(size_t)':
> ./src/include/jit/llvmjit_emit.h:78:22: error: 'TypeSizeT' was not declared in this scope
>   return LLVMConstInt(TypeSizeT, i, false);
>                       ^~~~~~~~~
> ./src/include/jit/llvmjit_emit.h: In function 'LLVMOpaqueValue* l_sbool_const(bool)':
> ./src/include/jit/llvmjit_emit.h:87:22: error: 'TypeStorageBool' was not declared in this scope
>   return LLVMConstInt(TypeStorageBool, (int) i, false);
>                       ^~~~~~~~~~~~~~~
> ./src/include/jit/llvmjit_emit.h: In function 'LLVMOpaqueValue* l_pbool_const(bool)':
> ./src/include/jit/llvmjit_emit.h:96:22: error: 'TypeParamBool' was not declared in this scope
>   return LLVMConstInt(TypeParamBool, (int) i, false);
>                       ^~~~~~~~~~~~~
> ./src/include/jit/llvmjit_emit.h: In function 'LLVMOpaqueValue* l_mcxt_switch(LLVMModuleRef, LLVMBuilderRef,
LLVMValueRef)':
> ./src/include/jit/llvmjit_emit.h:205:34: error: 'StructMemoryContextData' was not declared in this scope
>    cur = LLVMAddGlobal(mod, l_ptr(StructMemoryContextData), cmc);
>                                   ^~~~~~~~~~~~~~~~~~~~~~~
> ./src/include/jit/llvmjit_emit.h:205:34: note: suggested alternative: 'MemoryContextData'
>    cur = LLVMAddGlobal(mod, l_ptr(StructMemoryContextData), cmc);
>                                   ^~~~~~~~~~~~~~~~~~~~~~~
>                                   MemoryContextData
> ./src/include/jit/llvmjit_emit.h: In function 'LLVMOpaqueValue* l_funcnullp(LLVMBuilderRef, LLVMValueRef, size_t)':
> ./src/include/jit/llvmjit_emit.h:223:9: error: 'FIELDNO_FUNCTIONCALLINFODATA_ARGS' was not declared in this scope
>          FIELDNO_FUNCTIONCALLINFODATA_ARGS,
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ./src/include/jit/llvmjit_emit.h: In function 'LLVMOpaqueValue* l_funcvaluep(LLVMBuilderRef, LLVMValueRef, size_t)':
> ./src/include/jit/llvmjit_emit.h:241:9: error: 'FIELDNO_FUNCTIONCALLINFODATA_ARGS' was not declared in this scope
>          FIELDNO_FUNCTIONCALLINFODATA_ARGS,
>          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Evidently, llvmjit_emit.h doesn't meet the project standard that says
> it should be includable standalone (to ensure that header inclusion
> order isn't important in .c files).  It looks like it needs to #include
> llvmjit.h and fmgr.h to satisfy these references.  Is there a good
> reason why this wasn't done?

Not really a good one - it's not really meant as an API just a
collection of mini helpers for codegen, but there's no reason not to
make it self sufficient.

Will make them so.

Greetings,

Andres Freund