latest commit of panama-foreign branch jextract has strange error...

[Mark Hammons]

Hi Jorn,

This is what got the build working for me. While the README.foreign does 
mention the use of pre-packaged clang, it makes it seem much less necessary 
than it actually is for jextract's build. The configuration script accurately 
picked up on clang7 (or clang 9, whichever I had installed at the time) in my 
OS, and used it to generate jextract, but it seems the build process for 
jextract isn't well suited to anything that has a clang layout different from 
the downloadable clang (or maybe ubuntu).

Anyway, with that in place, my build is working (at least seemingly, need to 
run jtreg stuff on it), and my panama-foreign jdk is built.

One thing I'd like to mention. In an earlier discussion, Maurizio mentioned 
foreign-abi being a solution for something I was having trouble with. 
Naturally, I tried building it first, but it doesn't seem to have jextract or 
much of anything I rely on. Is there a version of the foreign branch that has 
the SystemABI api?

~Mark

On Friday, November 15, 2019 10:36:02 AM CET Jorn Vernee wrote:
> Hi Mark,
> 
> Due to a behavior breaking change in LLVM 8, jextract has required using
> LLVM 7, until a fix was released in LLVM 9 (which we've upstreamed).
> 
> I've been busy working on the foreign-abi branch, but you've reminded me
> about the plan to update to LLVM 9 once it came out. I've filed:
> https://bugs.openjdk.java.net/browse/JDK-8234237
> 
> If you want to build the foreign branch, I'd highly recommend trying to
> use one of the standard distributions of LLLVM 7:
> http://releases.llvm.org/download.html if you can, since our build
> scripts look for a particular directory structure. Then it should only
> be necessary to point `--with-libclang=</path/to/llvm/root>` to the root
> directory. Using the standard distribution also makes sure you have all
> the required dependencies  (libclang binary/libclang API headers/clang
> headers (aux)).
> 
> HTH,
> Jorn
> 
> On 15/11/2019 03:42, mark.hammons at inaf.cnrs-gif.fr wrote:
> > No, opensuse tumbleweed. I've tried a number of things, like "bash
> > configure --disable-warnings-as-errors
> > --with-jtreg=/home/mhammons/bin/jtreg --with-
> > libclang-include=/usr/include --with-libclang-include-aux=/usr/lib64
> > --enable- headless-only" but jextract still fails to find stddef.h. Do I
> > need to use a prebuilt clang that isn't from my linux distro?
> > 
> > 
> > On Friday, November 15, 2019 3:18:35 AM CET
> > 
> > sundararajan.athijegannathan at oracle.com  wrote:
> >> This does not appear to be due to last commit. Last commit was a hotspot
> >> fix to sync.  with latest hotspot code. That should not affect header
> >> file search. Are you on Mac?
> >> 
> >> -Sundar
> >> 
> >> On 15/11/19 5:51 am, Mark Hammons wrote:
> >>> I do not. This started happening with this build I'm trying to do of the
> >>> panama openjdk. I'm starting to think the stddef.h missing thing is on
> >>> my
> >>> side, cause some of the jtreg tests failed with that too. Trying to
> >>> figure
> >>> out why this is a problem for the build. Maybe it's because I'm using
> >>> clang 9.
> >>> 
> >>> ~Mark
> >>> 
> >>> On Friday, November 15, 2019 12:41:39 AM CET Maurizio Cimadamore wrote:
> >>>> Btw - are you saying you don't get this with the latest EA?
> >>>> 
> >>>> Maurizio
> >>>> 
> >>>> On 14/11/2019 23:38, Maurizio Cimadamore wrote:
> >>>>> Typically, the stddef.h not found problem comes from the fact that
> >>>>> jextract cannot find the clang support header files... is that a plain
> >>>>> call from command line? Which OS?
> >>>>> 
> >>>>> Thanks
> >>>>> Maurizio
> >>>>> 
> >>>>> On 14/11/2019 22:26, Mark Hammons wrote:
> >>>>>> Hi all,
> >>>>>> 
> >>>>>> When I use jextract from the latest panama-foreign commit
> >>>>>> (58596:ff086ae3cfac)
> >>>>>> I get the following error: java.lang.RuntimeException:
> >>>>>> /usr/include/zconf.h:
> >>>>>> 247:14: fatal error: 'stddef.h' file not found
> >>>>>> 
> >>>>>> it comes from this call of jextract: jextract /usr/include/zlib.h -L
> >>>>>> /usr/
> >>>>>> lib64 --record-library-path -l z -t zlib. I'm guessing this is a bug?
> >>>>>> 
> >>>>>> ~Mark