Re: [nativelibs4java] Bridj not loading dll, jna loads ok

[Kazó Csaba]

Hello,


This is a bit of a first guess, but I suggest that you pass the environment variables on the command line instead of using System.setProperty, because by then it might be too late. Especially the fact that you see no BridJ output indicates that these variables are read by BridJ earlier, before you set them. Using -Dbridj.debug=true on the command line will at least give you useful information like the search path.


Csaba

2013/2/22 Moises Ventura <moises...@gmail.com>

Hello:

I'm trouble using BridJ to load a dll in a JNAerator produced code, so I tried using minimum test classes (see attached) to troubleshoot the problem. The strange thing is the same dll loads without problems through JNA, fails without further information in BridJ. I am using bridj 0.6.2 jna 3.4.0 and jdk1.6.0_38 (brtdll.dll, CheckUsability.dll)

Does somebody have any ideas why BridJ would fail to load the library or how to troubleshoot the problem?

Thanks

***********Bridj**************

@Library("CheckUsability")

@org.bridj.ann.Runtime(CRuntime.class) 

public class LoadLibraryTest2 {

static {

    System.setProperty("java.library.path", ".\\src\\main\\resources");

    System.setProperty("bridj.veryVerbose", "true");

    System.setProperty("bridj.debug", "true");

    System.setProperty("bridj.logCalls", "true");

    System.setProperty("bridj.direct", "true");

BridJ.register();

}

***********JNA**************

public class LoadLibraryTest {

public static final String JNA_LIBRARY_NAME = "CheckUsability";

static {

  System.setProperty("jna.library.path", ".\\src\\main\\resources");

NativeLibrary JNA_NATIVE_LIB = NativeLibrary.getInstance(JNA_LIBRARY_NAME);

System.err.print(JNA_NATIVE_LIB.toString());

  }

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

[Olivier Chafik]

Hi Moises,

You've probably hit a an issue with dependent DLLs.

Can you try labelling brtdll as a dependency of CheckUsability?

    @Library("CheckUsability", dependencies = { "brtdll" })

I've identified the difference with JNA and filed a bug about that, I'll try to fix this asap:

    https://github.com/ochafik/nativelibs4java/issues/378

Cheers

--
Olivier
http://ochafik.com
http://twitter.com/ochafik

2013/2/22 Moises Ventura <moises...@gmail.com>

Csaba:

Thanks for your quick answer. 

The properties in the static initializer seem to be recognized properly, both by the dll locator and by the debugger (see attached bridj log)

I've played with different ways to locate the dlls () and they all seem to find the file properly. I stepped all the way down to the org.bridj.NativeLibrary.load(String path) method, and the path string is correct (full path to the dll). Nevertheless the JNI.loadLibrary(path); returns a 0 handle, with no errors or any further information.

In fact I did another quick test to verify the dll was properly located: This dll only works with Java 32 bits, so I did change the JRE from x86 to x64 and I got the expected error:

# BridJ: LoadLibrary error when loading C:\Users\mventura\AppData\Local\Temp\BridJExtractedLibraries7057517034870956580\CheckUsability.dll : %1 is not a valid Win32 application.

So it looks like the library is properly located, but not loaded in X86. I thought it might be due to other dll dependencies, but JNA loads it properly and the dependency walker doesn't show anything missing.

By the way, I'm surprised the  code uses that JNI implementation, since it seems to be deprecated (as per the java docs * @deprecated These methods can cause serious issues (segmentation fault, system crashes) if used without care : there are little to no checks performed on the arguments.)

Cheers

[Olivier Chafik]

Also, regarding the JNI.loadLibrary call being deprecated: this is an internal method from BridJ itself, which has to be public for some reasons (mainly, because it can be used from BridJ's subpackages) but should not be used by BridJ users (hence the deprecation ;-)).

The "little to no checks" mentioned are actually performed by BridJ's Java code, so you can rest assured that this should not be a source of system crashes ;-)

(thanks for watching out, though!)

Cheers

--
Olivier
http://ochafik.com
http://twitter.com/ochafik

2013/2/22 Moises Ventura <moises...@gmail.com>

Csaba:

Thanks for your quick answer. 

The properties in the static initializer seem to be recognized properly, both by the dll locator and by the debugger (see attached bridj log)

I've played with different ways to locate the dlls () and they all seem to find the file properly. I stepped all the way down to the org.bridj.NativeLibrary.load(String path) method, and the path string is correct (full path to the dll). Nevertheless the JNI.loadLibrary(path); returns a 0 handle, with no errors or any further information.

In fact I did another quick test to verify the dll was properly located: This dll only works with Java 32 bits, so I did change the JRE from x86 to x64 and I got the expected error:

# BridJ: LoadLibrary error when loading C:\Users\mventura\AppData\Local\Temp\BridJExtractedLibraries7057517034870956580\CheckUsability.dll : %1 is not a valid Win32 application.

So it looks like the library is properly located, but not loaded in X86. I thought it might be due to other dll dependencies, but JNA loads it properly and the dependency walker doesn't show anything missing.

By the way, I'm surprised the  code uses that JNI implementation, since it seems to be deprecated (as per the java docs * @deprecated These methods can cause serious issues (segmentation fault, system crashes) if used without care : there are little to no checks performed on the arguments.)

Cheers

[Moises Ventura]

Oliver:

You were right on the money! Adding the dependency parameter to the Library annotation solved the problem.

I added the following comment to your "http://code.google.com/p/bridj/wiki/FAQ" (see "Comment"). Hopefully your post and the wiki will save a few painful hours of head-wrecking debugging to someone.

Again, thanks a lot for your help.

**************************Comment**************

Could the following information be added to the "How do I debug a LoadLibrary : The specified module could not be found error ?" section:

When a library has dependent libraries they must be declared as:

    @Library("YourMainLibrary", dependencies = { "YourDependentLibraries" })

Failing to register the dependent library will throw a "The specified module could not be found error" error, even if all the libraries are present. Dependency walker will not detect this problem. JNA loads properly the dependent libraries without having to explicitly having to declare them. 

**************************

[Olivier Chafik]

Hi Moises,

Excellent suggestion, thanks, updated the FAQ :-)

Cheers