On Wed, 11 Mar 2020 at 13:47, Pavel Stehule <pavel.steh...@gmail.com> wrote:
>
> st 11. 3. 2020 v 6:43 odesílatel Julien Rouhaud <rjuju...@gmail.com> napsal:
>>
>> Le mer. 11 mars 2020 à 05:28, Laurenz Albe <laurenz.a...@cybertec.at> a
>> écrit :
>>>
>>> On Wed, 2020-03-11 at 11:25 +0800, Craig Ringer wrote:
>>> > 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.
>>>
>>> +1
>>>
>>> I have struggled with this, as have several users trying to build
>>> oracle_fdw.
>>
>>
>> +1, I had similar experience with other extensions.
>
> +1
BTW, as a workaround in the mean time you can suppress bitcode
generation by building your ext with:
make with_llvm=no all
Similarly, if postgres is not using your ccache for builds because
it's invoking a baked-in compiler path, you can run
make CC=$(type -p gcc) GCC=$(type -p gcc) all
to force fresh path-lookups that should find your ccache-wrappers for
the compiler.
This will also work around problems where ccache was used to build
postgres, so ccache-wrapper paths got baked into Makefile.in, so your
PGXS builds fail with something like:
make: /usr/lib64/ccache/gcc: Command not found
--
Craig Ringer http://www.2ndQuadrant.com/
2ndQuadrant - PostgreSQL Solutions for the Enterprise
