Architecture (32Bit<-->64Bit) dependend module depencencies

[Oliver Rettig]

Hallo,

I have a build a netbeans module, which depends on the java3d api. It is easy
to build a library wrapper module for the jars. But what to do with the
native libs? Different native libs for windows and linux are no problem. I
can put them in the lib/ext folder and only the needed ones are loaded based
on the files extentions.

But what to do with different architectures: 32bit versus 64bit?

Thanks for your help

Oliver Rettig

[Emilian Bold]

See http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html#jni
and http://platform.netbeans.org/articles/installation.html

specifically the part:

lib: contains native JNI libraries and basic boot files. The naming
policy of the libraries is in hands of the modules, as that it has
worked well enough till now. If it proves unsufficient following
conventions shall be obeyed: There are subdirectories under the lib
directory that reflect the architecture (e.g. i386, obtained via
System.getProperty ("os.arch")) and possibly also subdirectory
identifying the system (e.g. i386/linux, obtained via
System.getProperty ("os.name").toLowerCase ()). When the system is
looking for a particular library it scans the deepest directories
first and then the shallow ones (lib/i386/linux, lib/i386, lib).

--emi

On Thu, Oct 16, 2008 at 4:24 PM, Oliver Rettig <address-removed> wrote:

[Fabrizio Giudici]

But does this really work? The latest time we discussed about it (it was several months ago) I understood that the support for os.name etc... was a possible evolution for future and doesn't work at the moment. AFAIK the "library clash" problem exists and in fact it affects my application too. I hope I'm wrong...

Emilian Bold wrote:

[Emilian Bold]

Well, I never actually needed it, I was just pointing to the documentation.

On Linux though I know that hierarchy should be the way the linker
looks for libraries so I *think* it should work.

--emi

On Fri, Oct 17, 2008 at 11:42 AM, Fabrizio Giudici
<address-removed> wrote:

[mbien]

the doc is really misleading, it only suggests how you should do it, but does not say that this way is the supported way... etc

Also because it is common for many libraries to manage native lib loading by itself the suggested deployment strategy won't work anyway.

I decided to just circumvent the whole netbeans native library storry entirely and implemented a simple deployment mechansim by myself (aka results&simplicity first).

The idea is basically to deploy the correct natives on mudule install into the lib folder.

here is a "deployment descriptor" for jogl:
https://netbeans-opengl-pack.dev.java.net/source/browse/*checkout*/netbeans-opengl-pack/trunk/jogl/src/net/java/nboglpack/jogl/jogl-natives-config.xml?content-type=text%2Fplain&rev=397

here the native-lib-support module:
https://netbeans-opengl-pack.dev.java.net/source/browse/netbeans-opengl-pack/trunk/native-lib-support/src/net/java/nativelibsupport/

BTW, don't waste your time to file RFEs/BUGs against it they will be usually closed as "WONT FIX" especially short before releases where the devs will try to keep the bugcount low.

regards,

michael

[Fabrizio Giudici]

COLUMBUS' EGG!

Michael, you have probably already explained this to me earlier, but
I've understood it only now. It's neat!

mbien wrote:

[mbien]