0x6a77 / JD2XX

A JD2XX fork that supports OS X (x86_64) and Linux (x86, x86_64, arm7hf, arm7sf)
10 stars 10 forks source link

Does not work on Windows #4

Open alexvail opened 9 years ago

alexvail commented 9 years ago

I installed the .jar file in my local maven repository then added the dependency and all I can get is:

Exception in thread "main" java.lang.UnsatisfiedLinkError: jd2xx.JD2XX.getLibraryVersion()I at jd2xx.JD2XX.getLibraryVersion(Native Method)

I can instantiate a new JD2XX object just fine, but as soon as I call a native method (which is the point of this wrapper), it raises an exception. When I remove FTD2XX.dll it gives me a different error, so I'm really starting to think JD2XX.dll is broken. By the way I am using the 32 bits .DLL.

I also tried linking the .jar manually in Eclipse, and I still get the same error. Everything was working fine before when I was using this package: http://sourceforge.net/p/d2xx, but since this repo is more up-to-date I'd rather use this one if I can get it to work!

I know there haven't been an update in a while but I figured I might post here in case I could get some help, or help anyone else facing similar situation.

Thank you

0x6a77 commented 9 years ago

Likely the DLL is not on your native libraries path. There's two parts the JAR loader has to find.

Good luck!

Jeff

On May 19, 2015, at 11:10, alexvail notifications@github.com wrote:

I installed the .jar file in my local maven repository then added the dependency and all I can get is:

Exception in thread "main" java.lang.UnsatisfiedLinkError: jd2xx.JD2XX.getLibraryVersion()I at jd2xx.JD2XX.getLibraryVersion(Native Method)

I can instantiate a new JD2XX object just fine, but as soon as I call a native method (which is the point of this wrapper), it raises an exception. When I remove FTD2XX.dll it gives me a different error, so I'm really starting to think JD2XX.dll is broken. By the way I am using the 32 bits .DLL.

I also tried linking the .jar manually in Eclipse, and I still get the same error. Everything was working fine before when I was using this package: http://sourceforge.net/p/d2xx http://sourceforge.net/p/d2xx, but since this repo is more up-to-date I'd rather use this one if I can get it to work!

I know there haven't been an update in a while but I figured I might post here in case I could get some help, or help anyone else facing similar situation.

Thank you

— Reply to this email directly or view it on GitHub https://github.com/0x6a77/JD2XX/issues/4.

alexvail commented 9 years ago

Reason I posted here is that I've tried pretty much everything (I think). Copied it in system32, jdk's bin directory, added dll's folder in native library path. I always get the same error.

When I remove the FTD2XX.dll I get: Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Users\availlancourt\AppData\Local\Temp\jd2xx5581063458725435896.dll: The specified procedure could not be found

When I remove JD2XX.dll from the jar file I get: Exception in thread "main" java.lang.UnsatisfiedLinkError: File /jni/win/x86_32/jd2xx.dll was not found inside JAR. at jd2xx.JD2XX.(JD2XX.java:760)

So it seems to be able to find it and use it

Thank you for your quick answer

joanis commented 9 years ago

Have you tried calling System.load on the DLL?

I have this bit, which does the DLL loading:

String libPath = null;
String arch = System.getProperty("os.arch");
log.info("Architecture: " + arch);
if (arch.contains("64")) {
    libPath = new File("JD2XX64.dll").getAbsolutePath();
    System.load(libPath);
} else {
    libPath = new File("JD2XX.dll").getAbsolutePath();
    System.load(libPath);
}
0x6a77 commented 9 years ago

Where are the native FTDI libraries for your OS installed? I don't know windows so well, but those need to be on a path the loader can find as well.

On May 19, 2015, at 11:26, alexvail notifications@github.com wrote:

Reason I posted here is that I've tried pretty much everything (I think). Copied it in system32, jdk's bin directory, added dll's folder in native library path. I always get the same error.

When I remove the FTD2XX.dll I get: Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Users\availlancourt\AppData\Local\Temp\jd2xx5581063458725435896.dll: The specified procedure could not be found

When I remove JD2XX.dll from the jar file I get: Exception in thread "main" java.lang.UnsatisfiedLinkError: File /jni/win/x86_32/jd2xx.dll was not found inside JAR. at jd2xx.JD2XX.(JD2XX.java:760)

So it seems to be able to find it and use it

— Reply to this email directly or view it on GitHub https://github.com/0x6a77/JD2XX/issues/4#issuecomment-103623532.

alexvail commented 9 years ago

In system32 directory, they can be accessed from anywhere since system32 dir is in the PATH env. variable. As I said I get a different message when I remove the FTD2XX.dll versus when I keep it and try to call a native method, I don't think the problem is finding/loading the driver.

I tried System.load with the absolute location of FTD2XX.dll and it didn't raise an exception either.

alexvail commented 9 years ago

@joanis I get the same error when loading jd2xx.dll directly using System.load (java.lang.UnsatisfiedLinkError: jd2xx.JD2XX.getLibraryVersion()I at jd2xx.JD2XX.getLibraryVersion(Native Method))

lorenzop commented 9 years ago

here is how I found to fix the problem. http://dev.root1.de/projects/rxtx-rebundled/wiki while not ideal to use a repackaged version, it does work well for my own project. maybe this could be reviewed and merged into the official version if it's an acceptable solution? it's also available on maven central http://search.maven.org/#browse|1180100693

alexvail commented 9 years ago

RXTX != FTDI "RXTX is a native interface to serial ports in java." while jd2xx "is a Java native interface port of Future Technology Devices International (FTDI) D2XX direct USB driver." Thanks nonetheless

lorenzop commented 9 years ago

@alexvail my bad, read the comments but somehow didn't notice that. although, it does sound like a similar problem to what I had with rxtx on linux. the rebundled library uses a different class to handle loading the native dll/so files, which seems to be much more reliable. it might be worth trying the class in jd2xx.