Getting "UnsatisfiedLinkError" in io_uring for methods that were defined as "static inline" in the header

[Gavin Ray]

@Daniel, I didn't know the lwjgl folks were looking into this area, I've
had a brief look but it's definitely something I want to check out more!

@Maurizio, the idea about defining a second library that depends on it is
pretty clever.

It turns out that you can pull liburing in with CMake without so much effort
To set that scenario up was just the below code, this should work
decently 👍

=============================
ExternalProject_Add(
        liburing_git
        GIT_REPOSITORY http://github.com/axboe/liburing.git
        GIT_TAG liburing-2.2
        BUILD_IN_SOURCE 1
        BUILD_BYPRODUCTS "<SOURCE_DIR>/src/liburing.a"
        BUILD_COMMAND make
)
ExternalProject_Get_Property(liburing_git SOURCE_DIR)
add_library(liburing INTERFACE)
add_dependencies(liburing liburing_git)
target_include_directories(liburing INTERFACE ${SOURCE_DIR}/src/include)
target_link_libraries(liburing INTERFACE ${SOURCE_DIR}/src/liburing.a)

# NOW LINK IT TO SECOND LIBRARY
add_library(liburing_extras SHARED liburing_extras/main.c)
target_link_libraries(liburing_extras liburing)
add_dependencies(liburing_extras liburing)


On Wed, Sep 21, 2022 at 7:24 PM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

>
> On 21/09/2022 23:39, Gavin Ray wrote:
> > That makes sense -- I will look at patching liburing with a dirty
> > one-liner that strips "static inline" from the definitions that have
> > them then, ty =)
>
> Sorry, hit send too fast, and forgot to reply to this.
>
> There are few approaches that can be tried.
>
> First, you could define another shared library that depends on io_uring
> - e.g. a C file which includes the io_uring header. This new file would
> contain _new_ exported symbols for all the static inline functions,
> whose implementation just delegates to the underlying static inline
> functions (in the included io_uring header). Then you load up the
> library with Panama and, if you have set up things correctly, you will
> see both the static inlines and the exported symbols in IO uring. (in
> fact, we do a similar trick to expose system library symbols like
> "printf" on Windows, which implements them as macros).
>
> Another (more fun?) option would be to just keep the original library,
> and implement the static inline functions in Java directly, using the
> FFM API. Most of the functions I see have only 2-3 lines in them, so it
> shouldn't be hard.
>
> Maurizio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20220921/8ed1a20c/attachment.htm>