Building JNA from source

[Joe Smith]

I have been using JNA and it works well on Windows and Linux.

We will have a need to get it going on HP-UX Itanium, for which there is not a distribution.

In working toward that end, I have pulled the source and built on Linux (CentOS 7) to verify that it can be built and run from source on that system prior to trying to build on HP-UX.

The element that gets built is 'libjnidispatch.so'.

This is the same shared library that I find in the jna jar distribution file (jna-4.1.0.jar).

In order to verify that I have created something that will work, I decided to

1) break our app (by deleting the jna jar file)

2) then add in our built jna shared library jar

The problem is the app DOES NOT FAIL.

The app works just fine.

So, my question at this point is how can the JNA code function with no JNA jar file?

Is the shared library now included in the jre/jdk?

I have searched all of the java jar files and directories and find no reference to the shared library.

We have been thinking that we have been using jna-4.1.0.jar for JNA.

But if we delete it and the app still runs, how is the JNA being resolved and what version is it using?

[Timothy Wall]

Run with -Djna.debug_load.jna=true to see where the library is being loaded from.

Run with -Djna.nosys=true to avoid loading any system-installed JNA.

> --
> 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/d/optout.

[Bruce North]

Ok,

By enabling the proper JNA logging I was able to see what was going on.

I did not really delete the jna-4.1.0.jar file.

I just renamed it to RENAMED-jna-4.1.0.jar.

The log showed that the search process is happy if it finds any file with "jna" in the title.

So it was still finding and using the renamed file to locate the shared library.

When I completely removed the jar file, the app then failed as expected.

Thanks to jwalljava.

nor...@msn.com

> Subject: Re: Building JNA from source
> From: twal...@java.net
> Date: Thu, 24 Dec 2015 05:18:58 -0500
> To: jna-...@googlegroups.com

> 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/CXjk5K785BU/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to jna-users+...@googlegroups.com.

[Bruce North]

I am now trying to get the JNA jar that I created to work with our java application.

I extracted the distribution jar (jna-4.1.0.jar) and then substituted the Linux shared library that I built from the JNA source (com/sun/jna/linux-x86-64/libjnidispatch.so).

Created a new jar where the only difference is this shared library file.

The manifest dir/file and everything else is the same as the original.

It finds the shared library from the new jar but then shows an error.

I have tried adding "jna.nosys=true", but no change.

Below is the logged error.

Not sure what else to do???

---------------------------------------------------

Found library resource at jar:file:.../jna-FROM-SOURCE.jar!/com/sun/jna/linux-x86-64/libjnidispatch.so

Trying .../apache-tomcat-7.0.8/temp/jna-3506402/jna3353312873281828838.tmp

Found jnidispatch at .../apache-tomcat-7.0.8/temp/jna-3506402/jna3353312873281828838.tmp

There is an incompatible JNA native library installed on this system

(at .../apache-tomcat-7.0.8/temp/jna-3506402/jna3353312873281828838.tmp).

To resolve this issue you may do one of the following:

 - remove or uninstall the offending library

 - set the system property jna.nosys=true

 - set jna.boot.library.path to include the path to the version of the

   jnidispatch library included with the JNA jar file you are using

---------------------------------------------------

nor...@msn.com

---

From: nor...@msn.com
To: jna-...@googlegroups.com
Subject: RE: Building JNA from source
Date: Thu, 24 Dec 2015 11:40:00 -0500

[Timothy Wall]

Since you're building jna anyway, why not just use your newly built jar file?  Jna checks to ensure the versions of the JNI and jna code match.  The version in the sources is usually bumped after a release.

java -jar jna.jar will spit out the version information (although it'd be nice if the error message did as well)

Sent from my iPhone

[Bruce North]

Ok, I am able to generate jna jar from source on Linux-64.

It will build and run with our application just like the regular distribution jar does.

I have now moved the source to an HP-UX Itanium system and am trying to build there.

This is not a support platform so I would expect build errors.

When I try to build, I get the following error:

 "build.xml:260: OS/arch not supported (HP-UX/IA64N), edit build.xml and native/Makefile to add it."

So I have added what I think is required in build.xml and Makefile to make the ant build happy.

I now get past that error but move on to other errors.

Attached are the modified build files and the ant -verbose output.

Change points are marked by "??".

Not being an 'ant' expert, is there any specific JNA documentation that would tell me exactly what is needed when adding a new os/arch?

Thanks,

nor...@msn.com

---

From: twal...@java.net

Subject: Re: Building JNA from source

Date: Wed, 6 Jan 2016 09:21:53 -0500
To: jna-...@googlegroups.com

[Timothy Wall]

Typically you’d just look for the nearest similar target and duplicate/modify the lines for the new target. In build.xml, just about any target will do; in the Makefile, there’s just a short section per target that tweaks the compiler and linker settings (gcc, usually).

I have tried building for hpux and ia64 (separately), I don’t recall any specific tweaks. The VM I was using had some issues finishing all the JNA tests, which I think was more of a JNI interaction issue than anything to do with the compilation/build process.

> On Jan 11, 2016, at 6:11 PM, Bruce North <nor...@msn.com> wrote:
>
> Ok, I am able to generate jna jar from source on Linux-64.
> It will build and run with our application just like the regular distribution jar does.
>
> I have now moved the source to an HP-UX Itanium system and am trying to build there.
> This is not a support platform so I would expect build errors.
>
> When I try to build, I get the following error:
> "build.xml:260: OS/arch not supported (HP-UX/IA64N), edit build.xml and native/Makefile to add it."
>
> So I have added what I think is required in build.xml and Makefile to make the ant build happy.
> I now get past that error but move on to other errors.
>
> Attached are the modified build files and the ant -verbose output.
> Change points are marked by "??".
>
> Not being an 'ant' expert, is there any specific JNA documentation that would tell me exactly what is needed when adding a new os/arch?
>
> Thanks,
>
>
> nor...@msn.com
>
>
>

> <modfiedFiles.zip><ant-hp.txt>

[PRATYUSH SINGH]

Hi Joe

I have a similar situation. But since i'm new to this, I want to ask how did you build (procedures, commands?) from the source after downloading from github repo. I am trying to build it on Windows for now.  

Thanks

[Matthias Bläsing]

Hi Pratyush,

Am Montag, den 19.02.2018, 00:10 -0800 schrieb PRATYUSH SINGH:
>
> I have a similar situation. But since i'm new to this, I want to ask
> how did you build (procedures, commands?) from the source after
> downloading from github repo. I am trying to build it on Windows for
> now.
>

I think you are looking for:

https://github.com/java-native-access/jna/blob/master/www/Contributing.md
https://github.com/java-native-access/jna/blob/master/www/WindowsDevelopmentEnvironment.md

With all requirements met, building a full JNA jar is done by:

ant dist

To build just the native library, run

ant native

HTH

Matthias

[PRATYUSH SINGH]

Hi Matthias

Thanks for the timely reply. I'm able to build the jar but facing errors with 'ant native'. I have attached a pic of the same. I am using cygwin64 (+ gcc) on Windows 7 and would prefer to avoid using MSVC. Also, what does jnidispatch do?

Thanks

Pratyush  

[Matthias Bläsing]

Hey Pratyush,

Am Mittwoch, den 21.02.2018, 08:17 -0800 schrieb PRATYUSH SINGH:
> Thanks for the timely reply. I'm able to build the jar but facing
> errors with 'ant native'. I have attached a pic of the same. I am
> using cygwin64 (+ gcc) on Windows 7 and would prefer to avoid using

Please follow the advises in the recipe:

https://github.com/java-native-access/jna/blob/master/www/WindowsDevelopmentEnvironment.md#recipe-for-building-on-windows

I strongly advise to build with visual studio, but if you don't install
it, the installation will yield a cygwin installation with enough
components to build JNA native parts.

> MSVC. Also, what does jnidispatch do?

jnidispatch is the core of JNA, it is the glue between the java side
and libffi, which does the heavy lifting.

It is the part, that needs to be build for each supported platform.

HTH

Matthias

[PRATYUSH SINGH]

Hi Matthias,

I have followed the steps in the recipe. I have the updated Visual C++ BT (with Win 8.1 SDK). 

Now I'm getting this error when I run 'ant native' in the root directory (jna-master). 

----------------------------------------------------------------------------

native:

     [exec] Configuring libffi (amd64)

     [exec] configure: error: cannot find install-sh, install.sh, or shtool in "/cygdrive/c/jna-            master/native/libffi" "/cygdrive/c/jna-master/native/libffi/.." "/cygdrive/c/jna-master/native/l            ibffi/../.."

     [exec] make: *** [Makefile:480: ../build/native-win32-x86-64/libffi/.libs/libffi.a] Error 1

BUILD FAILED

C:\jna-master\build.xml:932: exec returned: 2

-----------------------------------------------------------------------------

[Matthias Bläsing]

Hey Pratyush,

Am Donnerstag, den 22.02.2018, 02:47 -0800 schrieb PRATYUSH SINGH:
> Hi Matthias,
>
> I have followed the steps in the recipe. I have the updated Visual C++ BT (with Win 8.1 SDK).
>
> Now I'm getting this error when I run 'ant native' in the root directory (jna-master).
> ----------------------------------------------------------------------------
> native:
> [exec] Configuring libffi (amd64)
> [exec] configure: error: cannot find install-sh, install.sh, or shtool in "/cygdrive/c/jna- master/native/libffi" "/cygdrive/c/jna-master/native/libffi/.." "/cygdrive/c/jna-master/native/l ibffi/../.."
> [exec] make: *** [Makefile:480: ../build/native-win32-x86-64/libffi/.libs/libffi.a] Error 1
>
> BUILD FAILED
> C:\jna-master\build.xml:932: exec returned: 2
> -----------------------------------------------------------------------------
>

Did you run "ant clean" to get a clean installation? If not - do so.
Recheck your cygwin installation this sound like libtool is not
installed.

HTH

Matthias

[PRATYUSH SINGH]

Hey Matthias

'ant native' worked after doing a clean. libtool was not an issue as it was already installed. 

Now that it's building with MSVBT, what all do I have to do if I have to use another compiler (or a cross-compiler), like c89 for example ? I simply tried to change $CC in native/Makefile to c89 but it didn't reflect.  

Thanks

Pratyush 

[Matthias Bläsing]

Hey,

Am Montag, den 26.02.2018, 03:07 -0800 schrieb PRATYUSH SINGH:
>
> 'ant native' worked after doing a clean. libtool was not an issue as
> it was already installed.
>
> Now that it's building with MSVBT, what all do I have to do if I have
> to use another compiler (or a cross-compiler), like c89 for example ?
> I simply tried to change $CC in native/Makefile to c89 but it didn't
> reflect.
>

if MSVC is not on the path, mingw is automaticly used - from the steps
here:

https://github.com/java-native-access/jna/blob/master/www/WindowsDevelopmentEnvironment.md

Just skip the invocation of vcbuildtools.bat, mingw will be picked up
from the cygwin path and the build will be done without msvc.

Other building modes (outside MSVC and mingw) are not supported. If you
want to improve the Makefile in the native folder, feel free to suggest
changes. If you modifiy it thou, please keep in mind, that the Makefile
must work on all supported platforms.

Greetings

Matthias