Hi,
Am 18.04.2017 um 11:15 schrieb Emmanuel Bourg:
> Le 18/04/2017 à 00:07, Emmanuel Bourg a écrit :
>
>> I'll get another look.
>
> I wrote a simple test case:
>
> import com.sun.jna.platform.unix.X11;
> public class JNATest {
> public static void main(String[] args) throws Exception {
> System.setProperty("jna.boot.library.name", "jnidispatch.foo");
> System.out.println("XAllocSizeHints: " +
> X11.INSTANCE.XAllocSizeHints());
> }
> }
>
> Compiled and executed with the system JNA jar:
>
> java -cp .:/usr/share/java/jna.jar:/usr/share/java/jna-platform.jar
> JNATest
>
> And this always works, even if the jna.boot.library.name property
> contains a bogus name.
>
> Renaming libjnidispatch.system.so to libjnidispatch.so triggers
> an UnsatisfiedLinkError.
>
> I checked again the JNA code and there is no other occurrence of
> jna.boot.library.* besides the ones removed in 4.2.2-3.
>
> This issue really looks like an embedded jar. If it isn't in netbeans
> directly, it could be in one of its dependencies.I must admit I don't know what's going wrong here. I have checked libnb-platform18-java again but I can't find embedded code copies of JNA. (I grepped for com.sun.jna). I have also made sure that no external jar files are downloaded at build time. [1] I suggest to reassign this bug to libnb-platform18-java for now. I will update the netbeans-platform-nojnabinaries.patch accordingly which will hopefully fix this permanently. If you or someone else find an embedded code copy of JNA in Netbeans or libnb-platform18-java, please let me know. Obviously this would be very disappointing after all the work that went into the packaging. Regards, Markus [1] https://sources.debian.net/src/libnb-platform18-java/8.1%2Bdfsg1-4/debian/patches/netbeans-platform-empty-binaries-list.patch/
signature.asc
Description: OpenPGP digital signature
