[External] : Re: OSX in6_addr no longer generates compilable code after commit aa5f250
Jorn Vernee
jorn.vernee at oracle.com
Wed Jul 17 16:57:10 UTC 2024
Jextract binaries are published at [1]. Those target the Java 22 FFM API.
If you're on x64 mac, I believe the LLVM
'clang+llvm-13.0.1-x86_64-apple-darwin.tar.xz' package on the page you
linked to should work.
> I still have to manually change the gradle version each time due to
Java 21, and then later Java 22.
The current Gradle version should work if you run gradle with Java 17 on
the PATH, and in JAVA_HOME. The JDK with which jextract is built is
picked up through the `jdk22_home` project property instead.
Jorn
[1]: https://jdk.java.net/jextract/
On 17-7-2024 18:09, Alison Gravley wrote:
> Yes, as I had no idea there were binaries anywhere. At least not on
> github or for darwin. I have been using this LLVM version from
> homebrew as everything had been "working" up until the change in
> January. I vaguely remember having a really hard time getting jextract
> to compile until I used the one from homebrew, but that was way back
> in October. I still have to manually change the gradle version each
> time due to Java 21, and then later Java 22.
>
> I am pretty sure the version updated recently when I ran some updates,
> but I was running some version of 17 originally.
>
> Homebrew clang version 18.1.8
> Target: arm64-apple-darwin23.5.0
> Thread model: posix
> InstalledDir: /opt/homebrew/opt/llvm/bin
>
> I can try the binary from here and try to get jextract to compile
> again, but this may take me some time if I run into compiler issues.
> https://github.com/llvm/llvm-project/releases/tag/llvmorg-13.0.1
> <https://urldefense.com/v3/__https://github.com/llvm/llvm-project/releases/tag/llvmorg-13.0.1__;!!ACWV5N9M2RV99hQ!PdZ4MZW1ADX6bdrgUuuqhCitifDvKcOwwMF80rjeU8QELXpCh2Oyigjyoe1LXT84Ml1aPTGD-suJe1_a8jFW5q90Egr8$>
>
> On Wed, Jul 17, 2024 at 11:15 AM Jorn Vernee <jorn.vernee at oracle.com>
> wrote:
>
> Hey,
>
> Are you building jextract yourself? Note that only LLVM version 13
> works, as the naming of unnamed structs and unions in later
> versions leads to these weird struct names.
>
> See also: https://bugs.openjdk.org/browse/CODETOOLS-7903480
>
> Jorn
>
> On 17-7-2024 17:09, Alison Gravley wrote:
>> I meant to send this months ago, but after commit
>> aa5f25003554dffa18289f1be535ea23f75c29c3, which is from January
>> 18, 2024, I can no longer use this tool on OSX (Arm) as the
>> generated wrapper for in6 is invalid and cannot compile. I think
>> the commit after this one is where the "--source" flag was removed.
>>
>> Basically, there are "unnamed at
>> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/netinet6/in6.h:153:2"
>> within the generated java that does not allow it to compile.
>>
>> I am not able to share the 3rd party library that I am using
>> jextract on due to licensing, but in.h is from the OS. I am
>> assuming this is being generated due to the library including these:
>>
>> ```
>> #include <signal.h>
>> #include <sys/socket.h>
>> #include <arpa/inet.h>
>> #include <netinet/tcp.h>
>> #include <netinet/in.h>
>> #include <netdb.h>
>> ```
>>
>> Back in January, the generated in6_addr.java looked like this:
>>
>> ```
>> import java.lang.invoke.MethodHandle;
>> import java.lang.invoke.VarHandle;
>> import java.nio.ByteOrder;
>> import java.lang.foreign.*;
>> import static java.lang.foreign.ValueLayout.*;
>> /**
>> * {@snippet :
>> * struct in6_addr {
>> * union __u6_addr;
>> * };
>> * }
>> */
>> public class in6_addr {
>>
>> public static MemoryLayout $LAYOUT() {
>> return constants$41.const$0;
>> }
>> /**
>> * {@snippet :
>> * union {
>> * unsigned char __u6_addr8[16];
>> * unsigned short __u6_addr16[8];
>> * unsigned int __u6_addr32[4];
>> * };
>> * }
>> */
>> public static final class __u6_addr {
>>
>> // Suppresses default constructor, ensuring
>> non-instantiability.
>> private __u6_addr() {}
>> public static MemoryLayout $LAYOUT() {
>> return constants$41.const$1;
>> }
>> public static MemorySegment
>> __u6_addr8$slice(MemorySegment seg) {
>> return seg.asSlice(0, 16);
>> }
>> public static MemorySegment
>> __u6_addr16$slice(MemorySegment seg) {
>> return seg.asSlice(0, 16);
>> }
>> public static MemorySegment
>> __u6_addr32$slice(MemorySegment seg) {
>> return seg.asSlice(0, 16);
>> }
>> public static long sizeof() { return $LAYOUT().byteSize(); }
>> public static MemorySegment allocate(SegmentAllocator
>> allocator) { return allocator.allocate($LAYOUT()); }
>> public static MemorySegment allocateArray(long len,
>> SegmentAllocator allocator) {
>> return
>> allocator.allocate(MemoryLayout.sequenceLayout(len, $LAYOUT()));
>> }
>> public static MemorySegment ofAddress(MemorySegment addr,
>> Arena scope) { return RuntimeHelper.asArray(addr, $LAYOUT(), 1,
>> scope); }
>> }
>>
>> public static MemorySegment __u6_addr$slice(MemorySegment seg) {
>> return seg.asSlice(0, 16);
>> }
>> public static long sizeof() { return $LAYOUT().byteSize(); }
>> public static MemorySegment allocate(SegmentAllocator
>> allocator) { return allocator.allocate($LAYOUT()); }
>> public static MemorySegment allocateArray(long len,
>> SegmentAllocator allocator) {
>> return
>> allocator.allocate(MemoryLayout.sequenceLayout(len, $LAYOUT()));
>> }
>> public static MemorySegment ofAddress(MemorySegment addr,
>> Arena scope) { return RuntimeHelper.asArray(addr, $LAYOUT(), 1,
>> scope); }
>> }
>> ```
>>
>> Now I get lines like this in the generated java. I attached the
>> full version:
>> private static final GroupLayout $LAYOUT = MemoryLayout.structLayout(
>> in6_addr.union (unnamed at
>> /Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk/usr/include/netinet6/in6.h:153:2).layout().withName("__u6_addr")
>> ).withName("in6_addr");
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20240717/e0d2ffaf/attachment-0001.htm>
More information about the jextract-dev
mailing list