Error with const variables

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Mon Dec 9 22:16:55 UTC 2024


Hi,
Jorn and I were looking into this one earlier today, and discovered a 
similar thing.

Now, with jextract it could be possible, in principle, to treat “const 
int x = 4” as a constant, and generate a “constant getter” instead of 
trying to get a segment that points at the storage holding the global 
variable (which is how jextract would normally translate global variables).

However, we got a bit stuck with string constant - e.g. if you have 
something like this:

|char* const z = "Hello"; |

jextract would end up generating something like this:

|/** * {@snippet lang=c : * char *const z Hello * } */ public static 
MemorySegment z() { class Holder { static final MemorySegment z = 
foo_h.LIBRARY_ARENA.allocateFrom("Hello"); } return Holder.z; } |

This is a bit unfortunate, because we will try to allocate a string, 
even though a region of memory with the string in it might be available 
if the global variable is made available by the shared library.

One thing we discussed was to, maybe tweak the accessor, so that if the 
global variable lookup fails, we return a newly allocated string 
constant instead. But it seems a bit convoluted.

In the meantime, there is a workaround you could do:

  * you could define a new header file which includes the original one,
    and which defines all the constants you want are defined using
    pre-processor macros |#define|
  * then you run jextract on both the new header file
  * you tell jextract not to generate bindings for the constant
    /variables/ - this can be done using jextract’s filtering options [1]

It’s a bit roundabout, but it should give you want you want (I hope!). 
In the meantime, we’ll keep thinking if there’s anything better we can 
do to deal with this use case. Thanks for bringing it to our attention!

Cheers
Maurizio

[1] - https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#filtering

On 09/12/2024 20:34, Adrian Trapletti wrote:

> Hi Maurizio
>
> Thx for the help.
>
> What I found out is that the issue is not jextract or the platform. 
> It's C vs C++ default external linkage vs default internal linkage for 
> const variable declarations (If you rename foo.c to foo.cpp, then the 
> symbol table does not contain x due to internal linkage. Only if it's 
> declared as "extern const int x = 4;" there is external linkage in 
> C++). In my project the header file is imported into a cpp file.
>
> Best,
> Adrian
>
> *Dr. Adrian Trapletti*
> CEO
>
> *Uster Metrics GmbH *|  Steinstrasse 9b, 8610 Uster, Switzerland
> P +41 32 512 83 63  | M +41 79 103 71 31
> a.trapletti at ustermetrics.com | www.ustermetrics.com 
> <https://urldefense.com/v3/__http://www.ustermetrics.com__;!!ACWV5N9M2RV99hQ!IFLIy2aJmgLaooCbWq_vPOt96l0G24YRJbrtwUnJQe4Ae_AV9plEysCzPrfvPBU32c26Sd3kLMrNWzQrC5o6euY-b2WMF4wJ$>
>
>
> This email message including any attachments is confidential and may 
> be privileged. It is intended solely for the use of the individual or 
> entity named on this message. It is provided for informational 
> purposes only and does not constitute an offer or invitation to 
> subscribe for or purchase any services or products. Any form of 
> disclosure, copying, modification or distribution is unauthorized. If 
> you are not the intended recipient, you are requested to please notify 
> the sender immediately and delete the message including any 
> attachments from your computer system network. Email transmission 
> cannot be guaranteed to be secure or error free as information could 
> be modified. We therefore do not accept responsibility or liability as 
> to the completeness or accuracy of the information contained in this 
> message or any attachments.
>
>
>
>
>
> On Mon, Dec 9, 2024 at 1:07 PM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> wrote:
>
>     Hi,
>     what OS/platform are you on?
>
>     I tried a small example on my Linux/x64:
>
>     |// foo.c const int x = 4; |
>
>     Then compiled to a shared library:
>
>     |gcc -shared -o foo.so |
>
>     Then, from jshell:
>
>     |jshell> import java.lang.foreign.*; jshell> SymbolLookup lookup =
>     SymbolLookup.libraryLookup("./foo.so", Arena.global()); lookup ==>
>     java.lang.foreign.SymbolLookup$Lambda/0x00007f8d6705ac18 at 4459eb14
>     jshell> lookup.findOrThrow("x"); $3 ==> MemorySegment{ address:
>     0x7f8dc403c000, byteSize: 0 } |
>
>     So, the symbol seems to be there, which is also confirmed by
>     |objdump|:
>
>     |foo.so: file format elf64-x86-64 DYNAMIC SYMBOL TABLE:
>     0000000000000000 w D *UND* 0000000000000000 __cxa_finalize
>     0000000000000000 w D *UND* 0000000000000000
>     _ITM_registerTMCloneTable 0000000000000000 w D *UND*
>     0000000000000000 _ITM_deregisterTMCloneTable 0000000000000000 w D
>     *UND* 0000000000000000 __gmon_start__ 0000000000002000 g DO
>     .rodata 0000000000000004 x |
>
>     (see last line)
>
>     I’d suggest to maybe check that (a) the shared library you are
>     using (.so or .dll) does contain the constant variable symbols
>     we’re trying to lookup and (b) that jextract is using a correct
>     symbol lookup (e.g. one that points to your library). For (b) you
>     might want to refer this for further guidance:
>
>     https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md#library-loading
>     <https://urldefense.com/v3/__https://github.com/openjdk/jextract/blob/master/doc/GUIDE.md*library-loading__;Iw!!ACWV5N9M2RV99hQ!IFLIy2aJmgLaooCbWq_vPOt96l0G24YRJbrtwUnJQe4Ae_AV9plEysCzPrfvPBU32c26Sd3kLMrNWzQrC5o6euY-bwjt5prT$>
>
>     Cheers
>     Maurizio
>
>     On 08/12/2024 15:38, Adrian Trapletti wrote:
>
>>     Hi,
>>
>>     I run jextract on
>>     https://github.com/ERGO-Code/HiGHS/blob/master/src/interfaces/highs_c_api.h
>>     <https://urldefense.com/v3/__https://github.com/ERGO-Code/HiGHS/blob/master/src/interfaces/highs_c_api.h__;!!ACWV5N9M2RV99hQ!IFLIy2aJmgLaooCbWq_vPOt96l0G24YRJbrtwUnJQe4Ae_AV9plEysCzPrfvPBU32c26Sd3kLMrNWzQrC5o6euY-b4S629Bv$>.
>>
>>
>>     If I use the Java bindings to access the const variables I get
>>     "java.lang.UnsatisfiedLinkError: unresolved symbol".
>>
>>     For example
>>     ...
>>     long sense = kHighsObjSenseMinimize();
>>     ...
>>
>>     results in
>>
>>     java.lang.UnsatisfiedLinkError: unresolved symbol:
>>     kHighsObjSenseMinimize
>>     at
>>     com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.lambda$findOrThrow$0(highs_c_api_h.java:44)
>>     at java.base/java.util.Optional.orElseThrow(Optional.java:403)
>>     at
>>     com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.findOrThrow(highs_c_api_h.java:44)
>>     at
>>     com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h$kHighsObjSenseMinimize$constants.<clinit>(highs_c_api_h.java:804)
>>     at
>>     com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.highs_c_api_h.kHighsObjSenseMinimize(highs_c_api_h.java:834)
>>     at
>>     com.ustermetrics.highs4j/com.ustermetrics.highs4j.bindings.BindingsTest.solveLinearProgramReturnsExpectedSolution(BindingsTest.java:32)
>>     at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>>     at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
>>
>>     (https://github.com/atraplet/highs4j
>>     <https://urldefense.com/v3/__https://github.com/atraplet/highs4j__;!!ACWV5N9M2RV99hQ!IFLIy2aJmgLaooCbWq_vPOt96l0G24YRJbrtwUnJQe4Ae_AV9plEysCzPrfvPBU32c26Sd3kLMrNWzQrC5o6euY-b-fAs9n_$>
>>     and run the unit tests)
>>
>>     What do I miss here?
>>
>>     Thx and best regards,
>>     Adrian
>>
>>     *Dr. Adrian Trapletti*
>>     CEO
>>
>>     *Uster Metrics GmbH *|  Steinstrasse 9b, 8610 Uster, Switzerland
>>     P +41 32 512 83 63  | M +41 79 103 71 31
>>     a.trapletti at ustermetrics.com  | www.ustermetrics.com
>>     <https://urldefense.com/v3/__http://www.ustermetrics.com__;!!ACWV5N9M2RV99hQ!IFLIy2aJmgLaooCbWq_vPOt96l0G24YRJbrtwUnJQe4Ae_AV9plEysCzPrfvPBU32c26Sd3kLMrNWzQrC5o6euY-b2WMF4wJ$>
>>
>>
>>     This email message including any attachments is confidential and
>>     may be privileged. It is intended solely for the use of the
>>     individual or entity named on this message. It is provided for
>>     informational purposes only and does not constitute an offer or
>>     invitation to subscribe for or purchase any services or products.
>>     Any form of disclosure, copying, modification or distribution is
>>     unauthorized. If you are not the intended recipient, you are
>>     requested to please notify the sender immediately and delete the
>>     message including any attachments from your computer system
>>     network. Email transmission cannot be guaranteed to be secure or
>>     error free as information could be modified. We therefore do not
>>     accept responsibility or liability as to the completeness or
>>     accuracy of the information contained in this message or any
>>     attachments.
>>
>>
>>
>>
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jextract-dev/attachments/20241209/793455cb/attachment-0001.htm>


More information about the jextract-dev mailing list