<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 18/02/2024 14:00, Manuel
Bleichenbacher wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAA7F5jKSsDA4QcCpOjfoLLLAKKeRbnx9hkKNUBpS39BjKMrsug@mail.gmail.com">
<div dir="ltr">Are the bitfield warnings part of the "spurious
missing dependency errors"? I would prioritize the issues
differently:
<div><br>
</div>
<div>
<ol>
<li>Spurious missing dependency errors: They rendered
jextract completely useless, on all platforms. I could
only make progress because I reverted to the older
pre-built binaries.</li>
<li>NullPointerException: In my case, it prevents me from
making any progress on macOS.</li>
<li>Bitfield warnings: With Windows.h, they result in more
than 1000 warnings. Now try to imagine a person that has
to figure out why jextract doesn't do what he/she expects?</li>
<li>Bad alignment when creating layouts for packed structs:
I'm not sure this has ever worked. I also had custom code
before. The resulting error message isn't really helpful.</li>
<li>no error generated for missing dependencies in array
types: It results in a compilation error that exactly
points at the right location, is easy to understand, and
the problem is easy to fix<br>
<br>
</li>
</ol>
<div>1 and 2 far more important because they have no
workaround.</div>
</div>
</div>
</blockquote>
<p>Technically this is not true. In the sense that (1) does have a
workaround - which is to tweak the filters passed to jextract.</p>
<p>As for (3), we're probably in a situation where some folks would
like to understand more about what's going on, and some find that
annoying. A one-size-fits-all might be difficult.</p>
<p>As you also noticed (in another email), (4) is indeed a
regression and will be fixed.<br>
</p>
<p>Maurizio<br>
</p>
<blockquote type="cite" cite="mid:CAA7F5jKSsDA4QcCpOjfoLLLAKKeRbnx9hkKNUBpS39BjKMrsug@mail.gmail.com">
<div dir="ltr">
<div><br>
</div>
<div>Regards</div>
<div>Manuel</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am So., 18. Feb. 2024 um
12:15 Uhr schrieb Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Thanks for the reports Manuel.</p>
<p>It seems to me that the very-recently-introduced feature
to catch broken dependencies needs some more ironing out
(understandable, as it's just fresh out of the press).</p>
<p>Overall, you seem to have reported the following issues:</p>
<p>* spurious missing dependency errors for stuff that is
not generated anyway (e.g. missing struct depends on
another missing struct)<br>
* no error generated for missing dependencies in array
types<br>
* NullPointerException when creating enum constants (it
seems like jextract here is returning a null declaration
tree for an enum constant... seems a very odd situation).<br>
* Bad alignment when creating layouts for packed structs</p>
<p>Is this list correct? Of these, it seems to me the latter
two are more important to fix, as they are clear
regression in behavior. The first two seem more (perhaps
annoying) "quality of life" issues with a newly introduced
feature.</p>
<p>Cheers<br>
Maurizio<br>
</p>
<p><br>
</p>
<div>On 18/02/2024 09:00, Manuel Bleichenbacher wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>With regards to "struct udev". I very much support
your last comment that this should work without
warnings.</div>
<div><br>
</div>
<div>"struct udev" is an opaque data structure. The API
only uses pointers to the struct but never reveals its
actual layout as it is an implementation detail and
can change from version to version. This is an
established and good pattern. And jextract should be
able to handle it.</div>
<div><br>
</div>
<div>Regards</div>
<div>Manuel</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am So., 18. Feb. 2024
um 09:53 Uhr schrieb Manuel Bleichenbacher <<a href="mailto:manuel.bleichenbacher@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">manuel.bleichenbacher@gmail.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">
<div>Hi Jorn</div>
<div><br>
</div>
<div>Regarding the dependencies: Do I get it
correctly? If a struct, e.g. epoll_event, includes
another struct, e.g. epoll_data, I have to
explicitly include both of them?</div>
<div><br>
</div>
<div>If this is the case, it's a bit annoying but
doable. It should probably be better documented
(or did I miss the documentation of this fact)?</div>
<div><br>
</div>
<div>Anyhow, it leads to the next issue (likely a
bug or limitation of jextract) with the generated
code for epoll_event and epoll_data (from
<sys/epoll.h>). When the generated class
epoll_event is accessed for the first time, it
crashes with:</div>
<div><br>
</div>
<div>Caused by: java.lang.IllegalArgumentException:
Invalid alignment constraint for member layout:
[a8(ptr):[*:b1]|i4(fd)|i4(u32)|j8(u64)](data)<br>
at
java.base/jdk.internal.foreign.layout.StructLayoutImpl.of(StructLayoutImpl.java:49)<br>
at
java.base/java.lang.foreign.MemoryLayout.lambda$structLayout$1(MemoryLayout.java:1063)<br>
at
java.base/jdk.internal.foreign.Utils.wrapOverflow(Utils.java:277)<br>
at
java.base/java.lang.foreign.MemoryLayout.structLayout(MemoryLayout.java:1062)<br>
at
net.codecrete.usb/net.codecrete.usb.linux.gen.epoll.epoll_event.<clinit>(epoll_event.java:29)<br>
</div>
<div><br>
</div>
<div>epoll_event is a tricky structure. It looks
like so:</div>
<div><br>
</div>
<div>typedef union epoll_data<br>
{<br>
void *ptr;<br>
int fd;<br>
uint32_t u32;<br>
uint64_t u64;<br>
} epoll_data_t;<br>
<br>
struct epoll_event<br>
{<br>
uint32_t events;<br>
epoll_data_t data;<br>
} __EPOLL_PACKED;</div>
<div><br>
</div>
<div>Because it's packed, the fields data.ptr and
data.u64 are not aligned.</div>
<div><br>
</div>
<div>It can be made to work if epoll_data.ptr and
epoll_data.u64 are set to a byte alignment of 4.
But that's not actually correct. epoll_data is not
a packed or unaligned struct. It's only unaligned
if used within another packed struct.</div>
<div><br>
</div>
<div>Regards</div>
<div>Manuel</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am So., 18. Feb.
2024 um 09:34 Uhr schrieb Manuel Bleichenbacher
<<a href="mailto:manuel.bleichenbacher@gmail.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">manuel.bleichenbacher@gmail.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">Hi Jorn
<div><br>
</div>
<div>Thanks for the prompt response. Using the
pre-built binaries, I've made some progress on
Linux but run into new issues. I will provide
the feedback one by one.</div>
<div><br>
</div>
<div>So let's start with the macOS. Here's the
output run with verbose.</div>
<div><br>
</div>
<div>I also propose to suppress the unrelated
warning that occurs on all platforms. It's
just annoying. And it will send newcomers in
the wrong direction when they actually have to
investigate real warnings or errors.</div>
<div><br>
</div>
<div>Regards</div>
<div>Manuel</div>
<div> </div>
<div><br>
</div>
<div>WARNING: A restricted method in
java.lang.foreign.AddressLayout has been
called<br>
WARNING:
java.lang.foreign.AddressLayout::withTargetLayout
has been called by
org.openjdk.jextract.clang.libclang.Index_h in
module org.openjdk.jextract<br>
WARNING: Use
--enable-native-access=org.openjdk.jextract to
avoid a warning for callers in this module<br>
WARNING: Restricted methods will be blocked in
a future release unless native access is
enabled<br>
<br>
Cannot invoke
"org.openjdk.jextract.Declaration$Constant.name()"
because "<parameter2>" is null<br>
java.lang.NullPointerException: Cannot invoke
"org.openjdk.jextract.Declaration$Constant.name()" because
"<parameter2>" is null<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.enumConstantString" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.enumConstantString</a>(TreeMaker.java:532)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.lambda$createEnum$7" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.lambda$createEnum$7</a>(TreeMaker.java:375)<br>
at
java.base/java.util.ArrayList.forEach(ArrayList.java:1597)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.createEnum" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.createEnum</a>(TreeMaker.java:373)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.createTreeInternal" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.createTreeInternal</a>(TreeMaker.java:133)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.createTree" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.impl.TreeMaker.createTree</a>(TreeMaker.java:119)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.Parser.lambda$parse$2" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.impl.Parser.lambda$parse$2</a>(Parser.java:86)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.lambda$forEach$1" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.lambda$forEach$1</a>(Cursor.java:261)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren$Context.visit" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren$Context.visit</a>(Cursor.java:234)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.lambda$static$0" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.lambda$static$0</a>(Cursor.java:252)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_visitChildren" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.clang.libclang.Index_h.clang_visitChildren</a>(Index_h.java:8275)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.forEachShortCircuit" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.forEachShortCircuit</a>(Cursor.java:271)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.forEach" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor$CursorChildren.forEach</a>(Cursor.java:260)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor.forEach" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.clang.Cursor.forEach</a>(Cursor.java:201)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.impl.Parser.parse" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.impl.Parser.parse</a>(Parser.java:64)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.parse" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.parse</a>(JextractTool.java:119)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.run" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.run</a>(JextractTool.java:516)<br>
at
<a href="mailto:org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.main" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">org.openjdk.jextract@22/org.openjdk.jextract.JextractTool.main</a>(JextractTool.java:218)<br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am Sa., 17.
Feb. 2024 um 20:46 Uhr schrieb Jorn Vernee
<<a href="mailto:jorn.vernee@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">jorn.vernee@oracle.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>One more thing I realized about the
warnings you get for
/usr/include/libudev.h: the structs about
which you get warnings are not being
included (looking at your script, there
are no --include-struct for them), so
there shouldn't be any need for us to warn
about them either.</p>
<p>We currently check whether things are
included first, and then mark things that
aren't as 'skipped'. However, in the later
pass which checks for unsupported types,
we also issue warnings for those skipped
elements. I think we should just skip
issuing warnings for things that are
marked as skipped by the earlier pass.<br>
</p>
<p>Jorn<br>
</p>
<div>On 17/02/2024 17:59, Jorn Vernee wrote:<br>
</div>
<blockquote type="cite">
<p>Hey Manuel,</p>
<p>Thanks for giving jextract 22 a try,
and sorry for the frustrating
experience.</p>
<p>- The <font face="monospace">NullPointerException
</font>is definitely a bug. Jextract
should not just report an exception.
We'll have a closer look at this on
Monday, and see if we can find what code
causes the issue. It would help if you
could edit the jextract launch script,
and add
`JLINK_VM_OPTIONS=-Djextract.debug=true`
(`JLINK_VM_OPTIONS=` should already be
there), and then retry the failed
extraction. This should print out more
information, including the entire stack
trace. that's the part I'm interested
in.<br>
<br>
<br>
> I don't understand the error
message. What does "xxx depends on yyy
which has been excluded" mean? Have I
used it incorrectly? The error message
mostly mentions types (and possibly
functions) that I don't use, neither
directly nor indirectly. </p>
<p>It is meant to tell the user that
they've included something that depends
on something else which was not
included. This would previously lead to
uncompileable code, since
FunctionDescriptors and MemoryLayouts
now refer directly to the layouts
defined in struct classes. For example,
if I have a function like `void
foo(struct A)`, then the
FunctionDescriptor for `foo` will depend
directly on the class we generate for
`struct A`:<br>
<font face="monospace"><br>
FunctionDescriptor.ofVoid(<br>
A.layout()<br>
);</font></p>
<p>If `A` itself is not included, this
code would be uncompileable. So, in the
latest version we (try to) issue an
error about that.</p>
<p>- For the 'ERROR's due to missing
dependencies you are seeing: this also
looks like a bug. We are currently
issuing errors if a _skipped_ symbols
depends on a skipped symbol as well,
which makes no sense. We can just ignore
missing dependencies of skipped things.
I've tried to implement a quick fix here
[1]. Though, you might be better off
using the pre-built binaries for now,
which don't have this dependency
scanning behavior in the first place
(i.e the builds at <a href="https://urldefense.com/v3/__http://jdk.java.net/jextract__;!!ACWV5N9M2RV99hQ!KoEDwvC86e2TU0EZbLrZSsTHJ4qTgslhzXYRSs-8WYRsAIIOv0tJGfjBTii3wim95U6oHMlE6NvDRgNfmeh_1a8kHCAPwrY5uA$" target="_blank" moz-do-not-send="true">jdk.java.net/jextract</a>)<br>
<br>
<br>
> And why are udev, udev_list_entry,
udev_device etc. skipped? They used to
work with jextract 21.</p>
<p>- I took a look at libudev.h, and the
warnings about unsupported types seem
correct to me. e.g. `struct udev` does
not have a definition in libudev.h [2],
so jextract can not generate a class for
it (since the layout and fields are not
known). That is all the the warning is
trying to say. The other structs about
which you get a warning seems to be the
same in that they don't have a
definition in that file. (FWIW this is
one of the areas we put a lot of effort
into, so it makes sense that you didn't
seen a warning in JDK 21). I think we
need to clarify the error message to say
more than "is not supported" though.<br>
<br>
<br>
> /usr/include/linux/usbdevice_fs.h:
The code generated for the struct
usbdevfs_urb does not compile (it refers
to a type usbdevfs_iso_packet_desc,
which is missing).</p>
<p>This is actually the situation we were
trying to detect with the ERRORs you
encountered. There should have been an
error about <font face="monospace">usbdevfs_iso_packet_desc</font>
being excluded, but it seems like we are
not scanning the element types of arrays
at the moment (linked PR tries to fix
this as well).<br>
<br>
<br>
And finally, yeah: we need to update the
README on the master branch to reference
JDK 22 instead of 21.<br>
</p>
<p>Thanks for reporting back! While we try
to test as much as possible, some issues
slip through the cracks, and are only
found through user feedback like yours.<br>
Jorn<br>
</p>
<p>[1]: <a href="https://urldefense.com/v3/__https://github.com/openjdk/jextract/pull/217__;!!ACWV5N9M2RV99hQ!KoEDwvC86e2TU0EZbLrZSsTHJ4qTgslhzXYRSs-8WYRsAIIOv0tJGfjBTii3wim95U6oHMlE6NvDRgNfmeh_1a8kHCAye_9J8A$" target="_blank" moz-do-not-send="true">https://github.com/openjdk/jextract/pull/217</a><br>
[2]: <a href="https://urldefense.com/v3/__https://github.com/systemd/systemd/blob/main/src/libudev/libudev.h*L20C1-L20C13__;Iw!!ACWV5N9M2RV99hQ!KoEDwvC86e2TU0EZbLrZSsTHJ4qTgslhzXYRSs-8WYRsAIIOv0tJGfjBTii3wim95U6oHMlE6NvDRgNfmeh_1a8kHCClAxRyzg$" target="_blank" moz-do-not-send="true">https://github.com/systemd/systemd/blob/main/src/libudev/libudev.h#L20C1-L20C13</a><br>
</p>
<div>On 17/02/2024 15:40, Manuel
Bleichenbacher wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Hi Maurizio
<div><br>
</div>
<div>I have tried to upgrade the
JavaDoesUSB library (<a href="https://urldefense.com/v3/__https://github.com/manuelbl/JavaDoesUSB__;!!ACWV5N9M2RV99hQ!KoEDwvC86e2TU0EZbLrZSsTHJ4qTgslhzXYRSs-8WYRsAIIOv0tJGfjBTii3wim95U6oHMlE6NvDRgNfmeh_1a8kHCCdkI4EIQ$" target="_blank" moz-do-not-send="true">https://github.com/manuelbl/JavaDoesUSB</a>)
from JDK 21 to 22, and it was very
frustrating. It failed on macOS,
Windows nor Linux. And the problem
is jextract.</div>
<div><br>
</div>
<div>(The header files I'm trying
the process are operating system
header files.)</div>
<div><br>
</div>
<div><br>
</div>
<div>On macOS, it always crashes:</div>
<div><br>
</div>
<div>FATAL: Unexpected exception
java.lang.NullPointerException:
Cannot invoke
"org.openjdk.jextract.Declaration$Constant.name()"
because "<parameter2>" is
null occurred<br>
</div>
<div><br>
</div>
<div>I've tried different branches
(master, panama, jdk22) and the
pre-built binaries. They all
behave the same except the error
message is sometimes shorter and
starts at "Cannot invoke..."</div>
<div><br>
</div>
<div>The full commands can be found
here (remove "--source"): <a href="https://urldefense.com/v3/__https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/macos/gen_macos.sh__;!!ACWV5N9M2RV99hQ!KoEDwvC86e2TU0EZbLrZSsTHJ4qTgslhzXYRSs-8WYRsAIIOv0tJGfjBTii3wim95U6oHMlE6NvDRgNfmeh_1a8kHCAc0b0ETw$" target="_blank" moz-do-not-send="true">https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/macos/gen_macos.sh</a></div>
<div><br>
</div>
<div><br>
</div>
<div>On Linux, jextract worked
partially. But for several files,
it refused to generate anything or
generated code that didn't
compile:</div>
<div><br>
</div>
<div>/usr/include/fcntl.h:</div>
<div>ERROR: stat depends on timespec
which has been excluded<br>
ERROR: stat depends on timespec
which has been excluded<br>
ERROR: stat depends on timespec
which has been excluded<br>
</div>
<div><br>
</div>
<div>/usr/include/libudev.h:</div>
<div>ERROR: __pthread_list_t depends
on __pthread_internal_list which
has been excluded<br>
ERROR: __pthread_slist_t depends
on __pthread_internal_slist which
has been excluded<br>
ERROR: __pthread_mutex_s depends
on __pthread_internal_list which
has been excluded<br>
WARNING: Skipping va_list (type
<error: struct
__va_list_tag> is not
supported)<br>
WARNING: Skipping __gnuc_va_list
(type <error: struct
__va_list_tag> is not
supported)<br>
WARNING: Skipping udev (type
Declared(udev) is not supported)<br>
WARNING: Skipping udev_list_entry
(type Declared(udev_list_entry) is
not supported)<br>
WARNING: Skipping udev_device
(type Declared(udev_device) is not
supported)<br>
WARNING: Skipping udev_monitor
(type Declared(udev_monitor) is
not supported)<br>
WARNING: Skipping udev_enumerate
(type Declared(udev_enumerate) is
not supported)<br>
WARNING: Skipping udev_queue (type
Declared(udev_queue) is not
supported)<br>
WARNING: Skipping udev_hwdb (type
Declared(udev_hwdb) is not
supported)<br>
</div>
<div><br>
</div>
<div>sys/epoll.h:</div>
<div>ERROR: __pthread_list_t depends
on __pthread_internal_list which
has been excluded<br>
ERROR: __pthread_slist_t depends
on __pthread_internal_slist which
has been excluded<br>
ERROR: __pthread_mutex_s depends
on __pthread_internal_list which
has been excluded<br>
ERROR: epoll_data_t depends on
epoll_data which has been excluded<br>
ERROR: epoll_event depends on
epoll_data which has been excluded<br>
</div>
<div><br>
</div>
<div>/usr/include/linux/usbdevice_fs.h:<br>
</div>
<div>The code generated for the
structusbdevfs_urb does not
compile (it refers to a
type usbdevfs_iso_packet_desc,
which is missing).</div>
<div><br>
</div>
<div>The full commands for jextract
can be found here. I've only
removed "--source" as it is no
longer needed.</div>
<div><a href="https://urldefense.com/v3/__https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/linux/gen_linux.sh__;!!ACWV5N9M2RV99hQ!KoEDwvC86e2TU0EZbLrZSsTHJ4qTgslhzXYRSs-8WYRsAIIOv0tJGfjBTii3wim95U6oHMlE6NvDRgNfmeh_1a8kHCAMG2KmUA$" target="_blank" moz-do-not-send="true">https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/linux/gen_linux.sh</a><br>
</div>
<div><br>
</div>
<div>All these files could
successfully be processed with
jextract 21.</div>
<div><br>
</div>
<div>I don't understand the error
message. What does "xxx depends on
yyy which has been excluded" mean?
Have I used it incorrectly? The
error message mostly mentions
types (and possibly functions)
that I don't use, neither directly
nor indirectly.</div>
<div><br>
</div>
<div>And why are udev,
udev_list_entry, udev_device etc.
skipped? They used to work with
jextract 21.</div>
<div><br>
</div>
<div><br>
</div>
<div>On Windows, it completely
failed as well. jextract outputs
more than 5000 lines of errors and
warnings. Here is just a random
selection:</div>
<div><br>
</div>
<div>ERROR: mbstate_t depends on
_Mbstatet which has been excluded<br>
</div>
<div>ERROR: LIST_ENTRY depends on
_LIST_ENTRY which has been
excluded<br>
</div>
<div>ERROR: depends on _M128A which
has been excluded<br>
</div>
<div>ERROR: WIN32_FIND_STREAM_DATA
depends on _WIN32_FIND_STREAM_DATA
which has been excluded<br>
</div>
<div>ERROR: tagEXTLOGFONTW depends
on tagLOGFONTW which has been
excluded<br>
</div>
<div>ERROR: MULTIKEYHELPW depends on
tagMULTIKEYHELPW which has been
excluded<br>
</div>
<div>WARNING: Skipping
MEM_EXTENDED_PARAMETER.Reserved
(bitfields are not supported)<br>
</div>
<div>WARNING: Skipping
Flags.Reserved (bitfields are not
supported)<br>
</div>
<div><br>
</div>
<div>The full command can be found
here (remove "--source"): <a href="https://urldefense.com/v3/__https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/windows/gen_win.cmd__;!!ACWV5N9M2RV99hQ!KoEDwvC86e2TU0EZbLrZSsTHJ4qTgslhzXYRSs-8WYRsAIIOv0tJGfjBTii3wim95U6oHMlE6NvDRgNfmeh_1a8kHCAYD8vM3w$" target="_blank" moz-do-not-send="true">https://github.com/manuelbl/JavaDoesUSB/blob/main/java-does-usb/jextract/windows/gen_win.cmd</a></div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>The REAMDE on <a href="https://urldefense.com/v3/__https://github.com/openjdk/jextract__;!!ACWV5N9M2RV99hQ!KoEDwvC86e2TU0EZbLrZSsTHJ4qTgslhzXYRSs-8WYRsAIIOv0tJGfjBTii3wim95U6oHMlE6NvDRgNfmeh_1a8kHCA-GJmmnA$" target="_blank" moz-do-not-send="true">https://github.com/openjdk/jextract</a>
could also profit from an update:</div>
<div><br>
</div>
<div>The command line "$ sh
./gradlew
-Pjdk21_home=<jdk21_home_dir>
..." sent me on search for the
branch with the JDK 22 code. But
it's just the README that's
outdated.</div>
<div><br>
</div>
<div>And the instruction "Run the
Gradle build with a Java version
appropriate for the Gradle
version. For example, Gradle 7.5.1
supports JDK 21." sent me down
another rabbit hole. I have the
latest Gradle version installed,
which nicely runs with JDK 21. But
it failed anyway. Turns out that
the installed gradle is irrelevant
but the gradle wrapper relevant
(see command line above). And the
gradle wrapper is at version
7.3.3. So there is nothing to
choose really. You must use JDK 17
(or even earlier). It has never
worked with JDK 21.</div>
<div><br>
</div>
<div><br>
</div>
<div>I would appreciate some
feedback. Are these bugs? Or has
jextract become so much more
restrictive?</div>
<div><br>
</div>
<div>Regards</div>
<div>Manuel</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Am
Fr., 16. Feb. 2024 um 16:50 Uhr
schrieb Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">maurizio.cimadamore@oracle.com</a>>:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
with JDK 22 near us, we have spent
some quality time with jextract,
to <br>
make sure the code it generates is
as good as it can be ahead of the
<br>
finalizaton of the FFM API. This
resulted in several changes, both
in <br>
the implementation (so, invisible
to jextract users) and in the <br>
generated code, as we cleaned up
the translation strategy to better
<br>
adhere with the core principles
behind the jextract tool. These
changes <br>
are captured in details in this
document:<br>
<br>
<a href="https://cr.openjdk.org/~mcimadamore/panama/jextract_changes.html" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://cr.openjdk.org/~mcimadamore/panama/jextract_changes.html</a><br>
<br>
It might be a good time to take
the latest jextract for a spin
(using <br>
your favourite C library!) and
report back, in case we missed
anything. <br>
You can find the latest sources in
this branch:<br>
<br>
<a href="https://urldefense.com/v3/__https://github.com/openjdk/jextract/tree/panama__;!!ACWV5N9M2RV99hQ!KoEDwvC86e2TU0EZbLrZSsTHJ4qTgslhzXYRSs-8WYRsAIIOv0tJGfjBTii3wim95U6oHMlE6NvDRgNfmeh_1a8kHCAk405RPw$" rel="noreferrer" target="_blank" moz-do-not-send="true">https://github.com/openjdk/jextract/tree/panama</a><br>
<br>
Binary snapshots of this newer
version are also available here
(note <br>
that MacOS/Arm64 builds is also
supported now):<br>
<br>
<a href="https://urldefense.com/v3/__https://jdk.java.net/jextract/__;!!ACWV5N9M2RV99hQ!KoEDwvC86e2TU0EZbLrZSsTHJ4qTgslhzXYRSs-8WYRsAIIOv0tJGfjBTii3wim95U6oHMlE6NvDRgNfmeh_1a8kHCA_GPVUpg$" rel="noreferrer" target="_blank" moz-do-not-send="true">https://jdk.java.net/jextract/</a><br>
<br>
Cheers<br>
Maurizio<br>
<br>
</blockquote>
</div>
</div>
</blockquote>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</body>
</html>