JNA on Linux-ARM

[Alex Lam S.L.]

I have had various answers on Google and get to know why the linux-arm
"libjnidispatch.so" is not included in the standard jna.jar yet.

In the mean time, is there anywhere I can download this file so as to
get going on my Stamp9G20?

Thanks,
Alex.

P.S. I have huge difficulties trying to get gcc to work on the
Angstrom distribution (too little disk space to install Debian...),
and although I managed to cross-compile the Linux kernel from an
Ubuntu PC, I can't see to get it to do the same for any ordinary
programs (keep getting "segmentation fault" when trying to execute the
compiled binary!)

[Timothy Wall]

The only thing lacking is a proper build platform. I've got a cross-compile for w32ce-arm, but everything else is built natively.

[Alex Lam S.L.]

By build platform do you mean the hardware? I have this for my development:

http://www.taskit.de/en/products/stamp9g20/index.htm

We are going to build our products based on units like this anyway, so
if you want a dedicated unit to build part of the JNA, I am more than
happy to provide.

Alex.

[Jonas Oscarsson]

Did anything happen with this? It is still the case libjnidispatch.so is not included in the downloadable jna.jar. However, it seems there's a debian package for libjna-java for armhf. That should work, right?

[Timothy Wall]

no, this never went anywhere.

any debian build for any supported platform should work, though.

> --
> You received this message because you are subscribed to the Google Groups "Java Native Access" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jonas Oscarsson]

OK. For others searching for this, it works done fine to use the libjna-java deb package, it has a libjnidispatch.so for armhf (I used the Ubuntu repo). Would of course rather have it in the jar from github, because the Ubuntu version is a bit old, but it works.

Thanks for answering!

[Jeff Crowder]

Jonas,

I have put together a cross-compile target that I have been using to build a libjnidispatch.so using arm-none-linux-gnueabi.

Timothy,

Is there any desire to get this into the official build?

-Jeff

[Rebecca Bird]

Jonas,

I have the libjnidispatch.so from libjna-java_3.2.7-4_armhf.deb, but am having trouble getting JNA to use it.  I have libjnidispatch.so stored in my pwd, and also /var/tmp/jni-root.  I gave libjnidispatch.so "rwx" modes for all groups.  I have tried:

    java -Djna.tmpdir="." -cp bin:purejavacomm.jar:jna-3.5.2.jar connect.Serial

    java -Djna.boot.library.path="." -cp bin:purejavacomm.jar:jna-3.5.2.jar connect.Serial

also the jna.nosys and jna.nounpack options.  No matter what I try, I get:

Exception in thread "main" java.lang.UnsatisfiedLinkError: canWriteDirectory

   at java.io.File.canWrite(File.java:163)

   at com.sun.jna.Native.getTempDir(Native.java:1003)

   at com.sun.jna.Native.removeTemporaryFiles(Native.java:1018)

   at com.sun.jna.Native.loadNativeLibrary(Native.java:677)

   at com.sun.jna.Native.<clinit>(Native.java:129)

This seems to indicate that the temporary directory can't be written in order to clear temporary files.  I am root, running on a Gumstix LPC11, and not a Linux pro.  Both /var/tmp and my working dir are writable.  How do I get JNA past this exception?

[Jonas Oscarsson]

Hi Rebecca,

Judging by the exception you are seeing it seems the exception is thrown because you have write permission to the folder/file (perhaps security issue and not allowed?). Try running chmod o-w,g-w file/folder. 

The only VM argument I'm passing to the JVM is -Djna.library.path=/some/non/standard/path/to/lib

/ Jonas

--
You received this message because you are subscribed to a topic in the Google Groups "Java Native Access" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jna-users/YFR9mgqfoLg/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to jna-users+...@googlegroups.com.

[Rebecca Bird]

Thanks, Jonas,

Suspect my installation Java 1.5 with CACAO 0.99.4 VM was missing the canWriteDirectory method in native class FileSystem, thus the java.lang.UnsatisfiedLinkError.  Updated to Java 1.6, and this exception was eliminated.  Also had to move back to jna-3.2.7.jar to be compatible with the libjnidispatch.so in libjna-java_3.2.7-4_armhf.deb.  Guess the linux_arm version of the native lib is not available for the more current jna-3.5.2.jar?

Appreciate your help.  BTW, is the VM argument you use actually -Djna.boot.library.path?

Rebecca

[Jonas Oscarsson]

Hi Rebecca,

Glad you got it working! No, as far as I know there's no native library for later versions of JNA, I used the debian package found in the Ubuntu repositories (libjna-java).

Where did you get -Djna.boot.library.path? I wrote -Djna.library.path :)

/ Jonas

--

[Rebecca Bird]

Thanks, Rick, for Java 8 tip. Maybe TWall or Nyholku will also see this from jna-users, for JTermios problem:

I installed Java 8, and now could compare these JVMs:
# java8 -version
java version "1.8.0-ea"
Java(TM) SE Runtime Environment (build 1.8.0-ea-b36e)
Java HotSpot(TM) Client VM (build 25.0-b04, mixed mode)
# java -version -cacao
java version "1.6.0_18"
IcedTea Runtime Environment (IcedTea6 1.8.2) (6b18-1.8)
CACAO (build 0.99.4, compiled mode)

I am running on Gumstix Overo ARMv7 rev 2 (v7l). My JNA is:
# java -Djna.boot.library.path=. -jar jna.jar
Java Native Access (JNA) API Version 3
Version: 3.2.7 (b0)
Native: 3.2.2 ()
Using the jna.jar provided by PureJavaComm, and the libjnidispatch.so from libjna-java_3.2.7-4_armhf.deb.

My serial test program can find connected devices, but can't open; here's the PureJavaComm log:
log: > open('ttyACM1',00000902)
log: < open('ttyACM1',00000902) => 97384
log: > close(97384)
log: < close(97384) => 185
log: > open('ttyACM1',00000902) (don't know why it opens and reopens...)
log: < open('ttyACM1',00000902) => 12
log: > fcntl(12, 3, 0)
log: < fcntl(12, 3, 0) => 97384
log: > fcntl(12, 4, 95336)
log: < fcntl(12, 4, 95336) => 1 (real problem is here)
log: JTermios call returned 1 at class purejavacomm.PureJavaSerialPort line 1075
log: > fcntl(12, 3, 0)
log: < fcntl(12, 3, 0) => 1085741088
log: > fcntl(12, 4, 1085741088)
log: < fcntl(12, 4, 1085741088) => 1085741088
log: fcntl(-1,4,1085741088) returned 1085741088
log: > close(12)
log: < close(12) => 1085741220

In case this is due to using older JNA code, I tried the newer versions of jna.jar and libjnidispatch.so. I collected jna.jar v3.5.2 and the library in linux-arm.jar from jna-master, but I get:
java -Djna.boot.library.path=. -jar jna.jar
Exception in thread "main" java.lang.Error:
There is an incompatible JNA native library installed on this system.
This could be version mismatch between native v3.4.0 and jna 3.5.2. Tried getting jna.jar v3.4.0 from github.com/twall/jna<http://github.com/twall/jna>, but still can't get versions to match.

Any more advice?
Thanks, Rebecca


On Apr 9, 2013, at 9:37 PM, Rick Fincher wrote:

Hi Rebecca,

Oracle has released the Java 8 early access for the arm (https://blogs.oracle.com/java/entry/developer_preview_of_java_se).

The Java 7 features are complete and stable. It is much faster than the Arm Open JDK JVM's.

It also has hardware floating point for the Arm processors that support it.

I'm using it on a Raspberry Pi with Debian (Raspbian), and JNA to access the Pi's I2C bus hardware. Works fine.

I'm using JNA 3.5.0. Haven't tried 3.5.2 with it yet.

I have a Tomcat web app that starts in under a minute. It took over 6 minutes to start with the fastest Open JDK install I was using.

I don't know if this will help you, but I thought I'd throw the info out there.

Rick

--
You received this message because you are subscribed to the Google Groups "Java Native Access" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com<mailto:jna-users+...@googlegroups.com>.

[Kustaa Nyholm]

On 10.4.2013 22.33, "Rebecca Bird" <bi...@bainet.com> wrote:

>Thanks, Rick, for Java 8 tip. Maybe TWall or Nyholku will also see this
>from jna-users, for JTermios problem:

I (nyholku) happened to see this, but it is better to contact
me directly or via the PJC mailing list pureja...@freelists.org
or via https://github.com/nyholku/purejavacomm.

I do hang around here but don't read every mail
of every thread and I guess this OT for this list.

>
>My serial test program can find connected devices, but can't open; here's
>the PureJavaComm log:

You can get a more detailed log (from the one
you provided the exact place in the source code where calls
occur is not 100% clear) if you do:

jtermios.JTermios.JTermiosLogging.setLogMask(255);

>log: > open('ttyACM1',00000902)
>log: < open('ttyACM1',00000902) => 97384
>log: > close(97384)
>log: < close(97384) => 185
>log: > open('ttyACM1',00000902) (don't know why it opens and reopens...)

If your code does CommPortIdentifier.getPortIdentifiers() then this
requires PJC to try to open the port because that is about the
only way to reliable check weather the portName is valid and to
throw NoSuchPortException, which cannot be thrown later when the
I try to really open the port.

>log: < open('ttyACM1',00000902) => 12
>log: > fcntl(12, 3, 0)
>log: < fcntl(12, 3, 0) => 97384
>log: > fcntl(12, 4, 95336)
>log: < fcntl(12, 4, 95336) => 1 (real problem is here)
>log: JTermios call returned 1 at class purejavacomm.PureJavaSerialPort
>line 1075

Obviously fcntl failed as it does below too:

>log: < fcntl(12, 4, 1085741088) => 1085741088
>log: fcntl(-1,4,1085741088) returned 1085741088

This looks strange too:

>log: > close(12)
>log: < close(12) => 1085741220

To me this looks like something is wrong with the
stack because fcntl(-1,4,1085741088) seems to return
the parameters it was passed (the -1 is red herring
caused by buggy log statement).

This can happen if my fcntl()/JNA mapping is wrong
or if there is a bug in JNA or the underlaying libffi
implementation for your platform.

My def looks like:

native public int fcntl(int fd, int cmd, int[] arg);

Hmm, looking at 'man fcntl' it seems that the third argument
should be 'long' (in C that is).

Looks like my bug then.



Now why does it work for me and everyone else?

Could be endian issues, don't recall if Raspberry/ARM
is big or little endian.

Anyway, more to the point, how to fix or workaround this?

Although the third argument for F_SETFD is 'long' it must
actually fit in 'int' as it is the value return from the
fcntl for F_GETFD, which is int.

So I guess changing the fcntl third argument to NativeLong
in Linux_C_lib_DirectMapping and Linux_C_lib and
changing jtermios.linux.JTermiosImpl.fcntl to:

public int fcntl(int fd, int cmd, int arg) {
return m_Clib.fcntl(fd, cmd, new NativeLong(arg));
}

could do the trick, don't have the time to implement and

test this right now but you could try that.


br Kusti


BTW I've heard that PJC has been successfully used on RaspberryPI
but I've also heard that the serial driver is very buggy. This
is not my firsthand knowledge.






This e-mail may contain confidential or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. We will not be liable for direct, indirect, special or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on or as of transmission of this e-mail in general.

[Timothy Wall]

On Apr 11, 2013, at 3:16 AM, Kustaa Nyholm wrote:

> On 10.4.2013 22.33, "Rebecca Bird" <bi...@bainet.com> wrote:
>
>> Thanks, Rick, for Java 8 tip. Maybe TWall or Nyholku will also see this
>> from jna-users, for JTermios problem:
>
>

> To me this looks like something is wrong with the
> stack because fcntl(-1,4,1085741088) seems to return
> the parameters it was passed (the -1 is red herring
> caused by buggy log statement).
>
> This can happen if my fcntl()/JNA mapping is wrong
> or if there is a bug in JNA or the underlaying libffi
> implementation for your platform.
>
> My def looks like:
>
> native public int fcntl(int fd, int cmd, int[] arg);
>
> Hmm, looking at 'man fcntl' it seems that the third argument
> should be 'long' (in C that is).
>

fcntl is actually variadic; the third argument might be anything, but "int[]" would only work if the particular call were expecting a pointer value. libffi only recently added explicit variadic function support; previous versions just set up the stack and hoped for the best (which usually worked).

[Kustaa Nyholm]

On 11.4.2013 14.17, "Timothy Wall" <twal...@java.net> wrote:
>
>fcntl is actually variadic; the third argument might be anything, but
>"int[]" would only work if the particular call were expecting a pointer
>value. libffi only recently added explicit variadic function support;
>previous versions just set up the stack and hoped for the best (which
>usually worked).

You are right of course. However luckily an other bug
in the code caused this piece of bad code not to be used!

Apparently I hand thought the third argument was a pointer
to int but 'man fcntl' says 'in most cases, the required type is long'
so I think the third argument really needs to be 'NativeLong' in
my case ... have not yet tested that though.

br Kusti