Re: Header checking failures on LLVM-less machines

From: Andres Freund <andres(at)anarazel(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Header checking failures on LLVM-less machines
Date: 2019-01-29 00:55:53
Message-ID: 20190129005553.tuydbrscrl454yqn@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2019-01-29 01:00:19 Re: jsonpath
Previous Message Tom Lane 2019-01-29 00:51:22 Re: Header checking failures on LLVM-less machines