Some small feedback regading jextract as a user

Jerven Tjalling Bolleman Jerven.Bolleman at sib.swiss
Thu Nov 12 22:50:21 UTC 2020


Hi Jorn,

Thank you so much for pointing that out.

That said I am still getting a

java.lang.RuntimeException: libhandlegraph-ffi-c.h:13:3: error: unknown 
type name 'HashGraph'

The libhandlegraph-ffi-c.h is now a C file, so that part worked.
Did you do anything special regarding your cargo build?
Sorry to ask, after you have been super helpful already!

Regards,
Jerven

On 2020-11-12 23:26, Jorn Vernee wrote:
> Hi,
> 
> On 12/11/2020 21:47, Jerven Tjalling Bolleman wrote:
>> Dear panama-devs,
>> 
>> I hope this feedback is in the useful category. My feedback is 
>> regarding the jextract tool and ffi. Most of it is trivial but I hope 
>> it is still useful.
>> 
>> No --version or -v option to quickly get the exact version of jextract 
>> (would make future feedback easier to pinpoint).
>> 
>> Assume the jextract user has minimal or no knowledge (like me) of how 
>> the library they want to wrap was built. For example the first error I 
>> ran into was “fatal error: 'cstdarg' file not found” which required 
>> “-C -x -C c++” to be added to the command. This was not intuitive and 
>> certainly not the first thing I tried (I started with trying different 
>> -I combinations. Specifically, I am trying to wrap a rust library with 
>> a header generated by rust cbindgen. So thinking of needing to add 
>> clang options to jextract was not high on my lists of things to do.
> The problem here seems that cbindgen produces a C++ header file, not a
> C file, and then exports a bunch of functions with C linkage (i.e.
> extern "C"). Note that jextract currently only handles C well, so
> parsing C++ will likely fail (e.g. with an NPE).
> 
> It looks like cbindgen supports generating C headers as well [1]. And,
> after some changes to your build.rs [2], jextract works with the
> following command:
> 
> jextract -l rs_handlegraph_ffi -t rs.handlegraph -d out 
> libhandlegraph-ffi-c.h
> 
> (Note that -l takes a library name, not a path). Producing the 
> following files:
> 
> out
> └───rs
>     └───handlegraph
>             C.class
>             libhandlegraph_ffi_c_h$atexit$x0.class
>             libhandlegraph_ffi_c_h$at_quick_exit$x0.class
> libhandlegraph_ffi_c_h$bsearch$_CompareFunction.class
> libhandlegraph_ffi_c_h$bsearch_s$_CompareFunction.class
>             libhandlegraph_ffi_c_h$constants$0.class
>             libhandlegraph_ffi_c_h$div_t.class
>             libhandlegraph_ffi_c_h$EdgeHolder.class
>             libhandlegraph_ffi_c_h$ldiv_t.class
> libhandlegraph_ffi_c_h$lfind$_CompareFunction.class
>             libhandlegraph_ffi_c_h$lldiv_t.class
> libhandlegraph_ffi_c_h$lsearch$_CompareFunction.class
>             libhandlegraph_ffi_c_h$mbstate_t.class
>             libhandlegraph_ffi_c_h$onexit$_Func.class
> libhandlegraph_ffi_c_h$qsort$_CompareFunction.class
> libhandlegraph_ffi_c_h$qsort_s$_CompareFunction.class
>             libhandlegraph_ffi_c_h$_CRT_DOUBLE.class
>             libhandlegraph_ffi_c_h$_CRT_FLOAT.class
>             libhandlegraph_ffi_c_h$_div_t.class
>             libhandlegraph_ffi_c_h$_LDBL12.class
>             libhandlegraph_ffi_c_h$_ldiv_t.class
>             libhandlegraph_ffi_c_h$_LDOUBLE.class
> libhandlegraph_ffi_c_h$_lfind$_CompareFunction.class
> libhandlegraph_ffi_c_h$_lfind_s$_CompareFunction.class
>             libhandlegraph_ffi_c_h$_lldiv_t.class
>             libhandlegraph_ffi_c_h$_LONGDOUBLE.class
> libhandlegraph_ffi_c_h$_lsearch$_CompareFunction.class
> libhandlegraph_ffi_c_h$_lsearch_s$_CompareFunction.class
>             libhandlegraph_ffi_c_h$_Mbstatet.class
>             libhandlegraph_ffi_c_h$_onexit$_Func.class
> libhandlegraph_ffi_c_h$_set_invalid_parameter_handler$_Handler.class
> libhandlegraph_ffi_c_h$_set_purecall_handler$_Handler.class
> libhandlegraph_ffi_c_h$_set_thread_local_invalid_parameter_handler$_Handler.class
> libhandlegraph_ffi_c_h.class
> libhandlegraph_ffi_c_h.class
>             libhandlegraph_ffi_c_h.class
>             RuntimeHelper$VarargsInvoker.class
>             RuntimeHelper.class
> 
> HTH,
> Jorn
> 
>> 
>> Having fixed that I ran into a null pointer exception. i.e.
>> WARNING: Using incubator modules: jdk.incubator.jextract, 
>> jdk.incubator.foreign
>> java.lang.NullPointerException
>> 
>> While we might dislike stack traces. I think a bug report (to myself 
>> regarding the C code) or to you would be easier to work on when you 
>> have a stack trace.
>> 
>> When generating the helloworld example I needed to compile with -fPIC. 
>> Which the document at
>> https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_jextract.md#jextract-a-jar-file-for-helloworldh 
>> claims generates a jar file but actually generates a directory with 
>> class files. The example worked fine with clang 10.0.1 but my fedora 
>> 10.2.1 gcc needed -fPIC.
>> 
>> Regarding the FFI interface, I would love to see more examples 
>> regarding the group layout functionality.
>> 
>> Otherwise with jextract I quite quickly ran into error: unknown type 
>> name without much of a suggestion why a certain type was not known. 
>> The libraries added to the command line should have had the types. And 
>> I am still working on this one.
>> 
>> That said the tools have lots of promise and please keep working on 
>> them!
>> 
>> Regards,
>> Jerven
> 
> [1] :  https://github.com/eqrion/cbindgen#quick-start
> [2] :
> 
> diff --git a/build.rs b/build.rs
> index 2dd7493..02b36e6 100644
> --- a/build.rs
> +++ b/build.rs
> @@ -7,6 +7,7 @@ fn main() {
> 
>      cbindgen::Builder::new()
>        .with_crate(crate_dir)
> +      .with_language(cbindgen::Language::C)
>        .generate()
>        .expect("Unable to generate bindings")
>        .write_to_file("libhandlegraph-ffi-c.h");

-- 
Jerven Tjalling Bolleman
SIB | Swiss Institute of Bioinformatics
CMU - 1, rue Michel Servet - 1211 Geneva 4
t: +41 22 379 58 85 - f: +41 22 379 58 58
Jerven.Bolleman at sib.swiss - http://www.sib.swiss



More information about the panama-dev mailing list