is this the issue that you faced with latest llvm?

[Maurizio Cimadamore]

This seems to fail on MacOs:

ib > checking libclang version to be used... 7 (default)
jib > checking libclang auxiliary include path... usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
jib > 	[-e pattern] [-f file] [--binary-files=value] [--color=when]
jib > 	[--context[=num]] [--directories=action] [--label] [--line-buffered]
jib > 	[--null] [pattern] [file ...]
jib > configure: error: Can not find libclang version matching the specified version: '7' in
jib >             /scratch/mesos/jib-master/install/jpg/infra/builddeps/libclang-macosx_x64/7.0.0+1.0/libclang-macosx_x64-7.0.0+1.0.tar.gz/lib/clang//7.0.0
jib > /scratch/mesos/slaves/df27b84d-b5c1-4760-9e48-df95fd33274c-S783/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/c479931a-1383-4646-a0d0-8e7355fd9205/runs/aefb5cb9-ffe4-4600-b811-dfe0055e18c6/workspace/build/.configure-support/generated-configure.sh: line 82: 5: Bad file descriptor
jib > configure exiting with result code 1


seems like an issue with grep?

Maurizio


On 03/05/2019 14:27, Maurizio Cimadamore wrote:
> I'll try this with our internal build infra used for EA first... :-)
>
> Maurizio
>
>
> On 03/05/2019 14:25, Jorn Vernee wrote:
>> I've made a quick patch that does some basic version checking and 
>> also allows selection of a specific LLVM version: 
>> http://cr.openjdk.java.net/~jvernee/panama/webrevs/llvmconf/webrev.00/
>>
>> This picks a version matching '7' by default, and allows specifying 
>> another version using e.g. --with-libclang-version=8, but also 
>> supports more complex version strings like 8.0.1 (using grep). If the 
>> selected version can not be found a config error is emitted. The 
>> version is ignored if --with-libclang-include-aux is specified 
>> manually (which is AFAIK the only place where the version matters).
>>
>> Jorn
>>
>> Maurizio Cimadamore schreef op 2019-05-03 14:30:
>>> The current system is mostly design to work with prebuilt binaries 
>>> here:
>>>
>>> http://releases.llvm.org/download.html
>>>
>>> You can point the Panama JDK to any binary snapshot you want in there
>>> and it just works (I tried earlier with several version to see if I
>>> was able to reproduce some issues).
>>>
>>> If you want the Panama build to work with system installation of
>>> clang/LLVM, you need to use separate configure options to tell the
>>> build where to find
>>>
>>> 1) the libclang includes
>>> 2) the libclang.so lib
>>> 3) the aux include files shipped with LLVM
>>>
>>> $ sh configure --help | grep clang   --with-libclang=<path to llvm>
>>>                           Specify path of llvm installation containing
>>>                           libclang. Pre-built llvm binary can be 
>>> downloaded
>>>                           from http://llvm.org/releases/download.html
>>>   --with-libclang-lib=<path>
>>>                           Specify where to find libclang binary, 
>>> so/dylib/lib
>>>   --with-libclang-include=<path>
>>>                           Specify where to find libclang header files,
>>>                           clang-c/Index.h
>>>   --with-libclang-include-aux=<path>
>>>                           Specify where to find libclang auxiliary 
>>> header
>>>                           files, 
>>> lib/clang/<clang-version>/include/stddef.h
>>>   --with-libclang-bin=<path>
>>>                           Specify where to find clang binary, 
>>> libclang.dll
>>>
>>> While this can be improved, it seems somewhat documented, and has
>>> worked for us so far.
>>>
>>> Doing --with-libclang=/usr/local/lib/clang/9.0.0/ doesn#'t really make
>>> sense in the current system.
>>>
>>> Maurizio
>>>
>>> On 03/05/2019 12:57, Jim Laskey wrote:
>>>> Allowing the specification of llvm locale on jextract itself would 
>>>> resolve these issues.