[External] : Re: jextract fails to work on sd-daemon.h due to wrong handling of __INCLUDE_LEVEL__

Mon Feb 17 14:56:27 UTC 2025

Yes, that warning is unrelated. It likely means that 
_sd_useless_struct_to_allow_trailing_semicolon_is only a declaration 
that does not have a definition, so no bindings will be generated for it.

Jorn

On 17-2-2025 14:12, Nils Kattenbeck wrote:
> Thanks, v22 works. I was checking with jextract 21 as that is the JDK 
> version I have running. With v22 everything seems to work, both when 
> specifying one or two header files. There are still a few warnings but 
> those seem unrelated:
>
> sd-daemon.h:26:1: warning: Skipping 
> _sd_useless_struct_to_allow_trailing_semicolon_ (type 
> Declared(_sd_useless_struct_to_allow_trailing_semicolon_) is not 
> supported)
>
>
> Cheers, Nils
>
> On Mon, Feb 17, 2025 at 2:04 PM Jorn Vernee <jorn.vernee at oracle.com> 
> wrote:
>
>     Looking at the code, we already unconditionally generate an
>     intermediate header file [1]. So this should already work on the
>     latest version of jextract.
>
>     Jorn
>
>     [1]:
>     https://github.com/openjdk/jextract/blob/7ed79ecdf678db804f40b3494b6f1dafa760c808/src/main/java/org/openjdk/jextract/JextractTool.java#L110
>     <https://urldefense.com/v3/__https://github.com/openjdk/jextract/blob/7ed79ecdf678db804f40b3494b6f1dafa760c808/src/main/java/org/openjdk/jextract/JextractTool.java*L110__;Iw!!ACWV5N9M2RV99hQ!Iw0EA9Y9KDQAmnT1W734TK58GyrdlXU9udm4XBJYBuYjQwu9PftFnhLsLnywJZ4adAjR2S4WJH1D6l4innKM$>
>
>     On 17-2-2025 14:00, Maurizio Cimadamore wrote:
>>
>>     I wonder how this interacts with the fact that jextract now also
>>     accepts multiple headers and, in that case, it will generate an
>>     intermediate header that includes the specified headers.
>>
>>     Can you try passing jextract _two_ headers, both sd-daemon.h and
>>     something else, and see what happens? My feeling is that things
>>     should work in that case.
>>
>>     Which, if true, would advocate for jextract to handle both cases
>>     in the same way: with an intermediate header including the
>>     specified header file(s).
>>
>>     Maurizio
>>
>>
>>
>>     On 15/02/2025 16:46, Nils Kattenbeck wrote:
>>>     Hi Jorn,
>>>
>>>     Your assessment seems to be correct. In C the main.c would be
>>>     level 0 which libclang sidesteps in this case. Creating a dummy
>>>     header file which simply includes the sd-daemon.h file seems to
>>>     fix the problem.
>>>
>>>     That being said I think it would still make sense for jextract
>>>     to work around this issue. Given that the resulting Java classes
>>>     would be similar to the main translation unit in C it would make
>>>     sense for jextract to emulate this behaviour and read the header
>>>     files as if they already were at level 1. This could e.g. be
>>>     done creating such a dummy header file automatically (like I now
>>>     did manually). This would better match expectations, resolve the
>>>     issue in this specific instance with systemd but more
>>>     importantly would prevent hard to troubleshoot issues in the future.
>>>
>>>     Cheers, Nils
>>>
>>>     On Fri, Feb 14, 2025 at 11:46 PM Jorn Vernee
>>>     <jorn.vernee at oracle.com> wrote:
>>>
>>>         Hey Nils,
>>>
>>>         Jextract uses clang under the hood to do the parsing, so it
>>>         is clang that is managing the __INCLUDE_LEVEL__ value, and
>>>         I'm assuming it does that correctly.
>>>
>>>         I think the issue here is that, normally, you would write a
>>>         program that includes sd-daemon.h, so the include level of
>>>         that file starts out at 1, with the main program translation
>>>         unit being level 0. But, since jextract uses clang to parse
>>>         the sd-daemon.h file directly, it has include level 0
>>>         instead, and this implementation header seems to end up with
>>>         include level 1, failing the check. You should see the same
>>>         error if you directly pass sd-daemon.h to clang (or gcc).
>>>
>>>         I think another way to work around this would be to create a
>>>         wrapper header file in which you #include sd-deamon.h, and
>>>         then pass that wrapper header file to jextract.
>>>
>>>         Jorn
>>>
>>>         On 13-2-2025 17:51, Nils Kattenbeck wrote:
>>>>         Dear all,
>>>>
>>>>         Today I tried to use jextract on sd-daemon.h (from systemd)
>>>>         to access the sd_notify* class of functions. To my surprise
>>>>         this did not work and returned in the following error message:
>>>>
>>>>         ../jextract-21/bin/jextract --source -t foo.bar
>>>>         /usr/include/systemd/sd-daemon.h
>>>>         WARNING: A restricted method in
>>>>         java.lang.foreign.AddressLayout has been called
>>>>         WARNING: java.lang.foreign.AddressLayout::withTargetLayout
>>>>         has been called by module org.openjdk.jextract
>>>>         WARNING: Use --enable-native-access=org.openjdk.jextract to
>>>>         avoid a warning for this module
>>>>
>>>>         /usr/include/systemd/_sd-common.h:23:4: error: "Do not
>>>>         include _sd-common.h directly; it is a private header."
>>>>
>>>>         which comes down to the following preprocessor code in
>>>>         _sd-common.h (which is included by sd-daemon.h):
>>>>
>>>>         #if defined(__INCLUDE_LEVEL__) && __INCLUDE_LEVEL__ <= 1 &&
>>>>         !defined(__COVERITY__)
>>>>         #  error "Do not include _sd-common.h directly; it is a
>>>>         private header."
>>>>         #endif
>>>>
>>>>         It seems like jextract does not increase the
>>>>         __INCLUDE_LEVEL__ resulting in this error. However, it does
>>>>         seem to define it which makes this more curious.
>>>>         The fix would be to either a) not set it at all or b)
>>>>         correctly increment it when parsing files from an  #include
>>>>         statement.
>>>>
>>>>         For now I have been able to circumvent this by telling
>>>>         jextract to also define __COVERITY__though this is only a
>>>>         very dirty hack and will not work in every instance.
>>>>
>>>>         Cheers,
>>>>         Nils
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20250217/ad636ec4/attachment-0001.htm>