Cannot use upstream libastyle

[NicoHood]

I cannot use the upstream libastyle library of archlinux like this:

sudo cp /usr/lib/libastyle-2.05.1.so /usr/share/arduino/lib/libastylej.so

However I am wondering why as opensuse for example also had those patches: https://build.opensuse.org/package/view_file/CrossToolchain:avr/Arduino/0004-libastylej-is-in-usr-lib.patch?expand=1

The error I get inside the IDE if i press ctrl+t:

Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: cc.arduino.packages.formatter.AStyleInterface.AStyleMain(Ljava/lang/String;Ljava/lang/String;)Ljava/lang/String;
    at cc.arduino.packages.formatter.AStyleInterface.AStyleMain(Native Method)
    at cc.arduino.packages.formatter.AStyle.run(AStyle.java:80)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
    at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
    at java.awt.EventQueue.access$500(EventQueue.java:97)
    at java.awt.EventQueue$3.run(EventQueue.java:709)
    at java.awt.EventQueue$3.run(EventQueue.java:703)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

I also has similar issues with ctags or liblistserial. Could you please provide some help why those upstream binaries dont work and how to patch them?

[kevans91]

So, the problems you're facing are pretty much because JNI is kind of funky/irritating in how it locates the proper symbols on the C side. As a likely slightly incorrect explanation, it's very picky in that if you have a class in a package, proessing.app.Platform, then calling resolveDeviceAttachedToNative() on this object will lookup the C symbol Java_processing_app_Platform_resolveDeviceAttachedToNative(), without falling back to a more generic symbol if that one's not found (Java_Platform_resolveDeviceAttachedToNative(), or anything along those lines).

You can see where this might be a problem -- if this JNI function is provided by a third party library, then there's almost no way the third party can provide this in a way that's useful to all of the potential consumers of this function. As such, there's some Arduino-specific patches that have to be applied before building these things.

For libserialport, see:

https://github.com/arduino/listSerialPortsC

Note that this actually provides their implementation of a couple of functions

For astyle, see this particular patch:

https://github.com/arduino/astyle/blob/master/patches/java_package_name.patch

Ctags is a little more complicated, because it's not /really/ ctags but a fork of Ctags (now unmaintained) that mixes in anjuta-tags. See:

https://github.com/arduino/ctags

[NicoHood]

Thanks for the explanation. But isnt there a way for arduino to still use those upstream libraries?

[kevans91]

Negative, unfortunately. You can't force JNI to fallback to a generic name lookup.

In the case of libserialport, they provide the full JNI impl. rather than patching an existing one.

For ctags, upstream is just blatantly wrong because theirs is a fork. There was talk of changing impl. to another fork somewhere.

[facchinm]

As @kevans91 perfectly stated, the problem with jni libs is that they are intended to be "included" in the class / library (so in the resulting jar) they are targeting. Since arduino is bigger than a jar it becomes very difficult to use the upstream version unless the classpath is the same. A nice summer project would be wrapping these files into a jar file and proving them with the correct namespace :smile: