Some small feedback regading jextract as a user
Jerven Tjalling Bolleman
Jerven.Bolleman at sib.swiss
Thu Nov 12 23:33:09 UTC 2020
Hi Jorn,
I got it you where on commit 9cf693a0ddb33357f35b02e79f9b3fa848e9cca9
Where jextract works with your build.rs fix.
I was on commit 9cb2fbcc257b5e7665a57a036ec170a0f8c67333
where it does not with the error I showed earlier (also with your
build.rs fix).
I will investigate a bit more tomorrow.
Again thank you very much for your help.
Regards,
Jerven
On 2020-11-13 00:08, Jorn Vernee wrote:
> Hi Jerven,
>
> No, I did not do anything special, I just followed your instructions
> in your reply to Maurizio (running `cargo build` with the modified
> build.rs was all I did).
>
> FWIW, the file I get out of cbindgen does not include 'HashGraph'
> anywhere, and the line 13 that supposedly throws the error is empty in
> my file [1].
>
> Jorn
>
> [1] :
>
> #include <stdarg.h>
> #include <stdbool.h>
> #include <stdint.h>
> #include <stdlib.h>
>
> typedef struct CGraph CGraph;
>
> typedef struct EdgesIter EdgesIter;
>
> typedef struct HandlesIter HandlesIter;
>
> typedef struct PathsIter PathsIter;
> // <-- line 13
> typedef struct {
> uint64_t left;
> uint64_t right;
> } EdgeHolder;
>
> CGraph *load_hashgraph(const uint8_t *file_name, uintptr_t
> file_name_len);
>
> void free_hashgraph(CGraph *graph);
>
> HandlesIter *graph_handles(const CGraph *graph);
>
> void free_handles_iter(HandlesIter *handles);
>
> uint64_t handles_next(HandlesIter *handles);
>
> bool handles_has_next(HandlesIter *handles);
>
> EdgesIter *graph_edges(const CGraph *graph);
>
> void free_edges_iter(EdgesIter *handles);
>
> EdgeHolder edges_next(EdgesIter *edges);
>
> bool edges_has_next(EdgesIter *edges);
>
> PathsIter *graph_paths(const CGraph *graph);
>
> void free_paths_iter(PathsIter *paths);
>
> int64_t paths_next(PathsIter *paths);
>
> bool paths_has_next(PathsIter *paths);
>
> On 12/11/2020 23:50, Jerven Tjalling Bolleman wrote:
>> 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://urldefense.com/v3/__https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_jextract.md*jextract-a-jar-file-for-helloworldh__;Iw!!GqivPVa7Brio!ORVvc0YKf1IezH9e1ZzHs3kEoc7rXWUi_45S5WOZw9LQeW859IDHJq7ySlh27tcF$
>>>> 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://urldefense.com/v3/__https://github.com/eqrion/cbindgen*quick-start__;Iw!!GqivPVa7Brio!ORVvc0YKf1IezH9e1ZzHs3kEoc7rXWUi_45S5WOZw9LQeW859IDHJq7ySlzVd6-F$
>>> [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