jextract fails to work on sd-daemon.h due to wrong handling of __INCLUDE_LEVEL__

[Jorn Vernee]

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/20250214/8217e451/attachment-0001.htm>