Background: I need to communicate my computer (Win7 64bit) to a PIC18F4550 using the USB port. I found the jpicusb library for Java, but it is compiled to work in 32bit OS. When I attemp to use it on my computer it does not recognize the jpicusb.dll file (which is needed). Some other posts on the internet say that happens because the .dll is built for 32bits OS.
Question: The files in the link contain the sources of the .class, .dll (I think?) and examples of how to use the .class. How can I compile the .dll source into a 64bit version .dll?
I would prefer not to use a VM to run a 32bit OS.
If you know how to communicate PIC to a PC in C or Java please tell me how to.
I've tried adding -m64 -march=x86-64 to the gcc command with no results
Some say the code makes it compile for 32bit but I don't know how that is possible.
I know libusb also does the work but I haven't tried it out (I wanted to completely discard jpicusb)
Related
I have a jar file 'myApp.jar' that I need to run through command line. When I run the jar on linux server it working perfect. However, when I tried to the same jar on mac terminal I am getting this error message:
Exception in thread "main" java.lang.UnsatisfiedLinkError: while loading kognac-core: Stream closed
at karmaresearch.vlog.VLog.loadLibrary(VLog.java:72)
at karmaresearch.vlog.VLog.<clinit>(VLog.java:22)
at org.semanticweb.rulewerk.reasoner.vlog.VLogReasoner.<init>(VLogReasoner.java:82)
at org.semanticweb.rulewerk.client.picocli.MyApp.someMethod(MyApp.java:150)
at org.semanticweb.rulewerk.client.picocli.MyApp.main(MyApp.java:110)
The command that I used to run the jar is:
java -jar myApp.java
The jar file is compiled and created by javaSE-1.8 through Eclipse on Mac.
The java version of Linux server is openjdk version "1.8.0_292"
The java versions on Mac are 3: Java SE 11.0.1(default version) , 1.8.0_202, 1.8.0_201 by these commands:
/Library/Java/JavaVirtualMachines/jdk1.8.0_201.jdk/Contents/Home/bin/java -jar myApp.java
/Library/Java/JavaVirtualMachines/jdk1.8.0_202.jdk/Contents/Home/bin/java -jar myApp.java
I tried to run the jar file on mac with all 3 java versions, but still getting the same error above.
How could I resolve this error on Mac terminal?
The problem isn't related to your app or how you run it.
Your app uses the karmaresearch project which I'm not familiar with (possibly, that's your own code, that you / your team wrote?) and this code attempts to load a so-called native library: These are libraries compiled straight for the OS/architecture your JVM is running on top of.
These take the form of a .jnilib file on mac, .dll on windows, and .so on linux and other posix-based OSes.
Native libraries are incredibly convoluted to ship: You need 1 such file for each combination of OS and underlying architecture. So, these days, you'd need at a minimum to make a reasonable claim that you're 'portable':
Mac AAarch64
Mac x84
Windows x64
Linux AArch64
Linux x64
Linux x32
BSD x64
and that's just a bare bones minimum.
These files cannot be inside the jar when you load them. The usual procedure is to obtain a location you can write to and load code out of (tricky), unpack the right file for the host OS to this folder, and then loadLibrary it. This is all very complicated. In general, either [A] you wrote karmaresearch and you need to think long and hard about using native libraries first, and if you truly need it, follow a tutorial, or [B] it's not your code, in which case you can't run this on a mac, at all, and there's nothing you can do about that, other than contact the makers of this library and ask them to add support for this.
I exported Processing application as a standalone application with embedded Java, but the exe does not work in computers where Java/Processing is not installed. Even if the Windows 64 bits works with Java embedded, the 32 bits does not work with Java embedded or not. The computers that do not have Java already installed open the Windows 64 bits exe but not the Windows 32 exe (with java embedded in its exporting process). Here's the post in Processing forum: https://forum.processing.org/two/discussion/25373/no-export#latest
Can it be resolved? Thanks.
You can only include the Java version for the type of machine you're running on.
If you're on a 64-bit Windows machine, then you can only include Java in the 64-bit Windows application. If you're on a 32-bit Linux machine, then you can only include Java in the 32-bit Linux application.
If you really want to include Java for a bunch of different machines, then your best bet is to find each type of machine and do the export from them. Find a 32-bit Windows machine and do the export there, then find a 64-bit Linux machine and do the export there, etc.
You might be able to hack something together by downloading the JRE for each type of machine and manually including it, but that might get pretty tricky. Note that this is not as simple as just copying a folder into your application directory. You're going to have to change the run script file as well.
Shameless self-promotion: I've written a tutorial on exporting applications from Processing available here.
I faced this issue many a times while working with a new setup or after a Java upgrade. Logical solution for this? Except replacing jvm.dll file?
Never realized, but the solution is quite easy. As per my understanding:
Observations:
If you are using a 64bit Windows system, then you would notice that there are two Program Files folder in your C:/ Drive.
That means, Program Files, which contains 64-bit programs and applications, and. Program Files (x86), which contains 32-bit programs and applications.
Now if you are using a 64bit system, then it is easy and recommended that you use softwares as well of 64bit. So your Path in System variables should contain the path details of your Java 64bit.
Now coming back to the original problem, here if we are on 64Bit Microsoft Windows system and wish to use 64bit Software (Eclipse for example), then let us set the Path for the 64bit Java.
Then make a simple test on command prompt.
-cmd
-java -version
Shows the 64bit Java VM is set to path.
Now Open your Eclipse and it do not show the Error.
Always remember that we should use:
64 bit OS
64 bit Java (with Path set for 64 bit Java)
64 bit Eclipse.
I tried GCJ and it compiled fine. I tried both for Ubuntu and windows. The compiled file is running on my Ubuntu machine as well the .exe with wine. But if I tried to run in on my Ubuntu server I got this error:
error while loading shared libraries: libgcj.so.14: cannot open shared object file: No such file or directory
But I thought I would not need to install anything to run "native" code. I also could not run the .exe on a windows machine.
Could you please tell me why this is happening? Maybe I'm compiling wrong. I use this: gcj --main=Hello -o hello.exe Hello.jar for windows.
When you run an executable it is very common to need a shared library, whether you use Visual Studio .NET or Java or C++.
When you compile a program for a specific platform, it usually only works on that platform or similar. If you want to run this program on Windows, you need to compile it for windows.
BTW GCJ is pretty old and out of date. I suggest you use Java 7 or 8. This will avoid the need to install additional libraries and will run on Windows or Linux without re-compiling.
For accessing FTDI USB boards from Java applications, I'm using the JD2XX driver wrapper (JD2XX.dll). It works very fine on 32-bit systems, but when it is loaded from a 64-bit JVM, it says it is impossible for a 64-bit JVM to load a 32-bit DLL. Very understandable. To get past this little problem, I install a 32-bit JVM on the 64-bit systems and it runs fine. Very simple solution, which can become very complicated to explain to a customer, though!
For this reason, I would like to create or otherwise obtain a 64-bit version of this JD2XX.dll file. I would like to know if someone ever did this successfully, or how I could proceed. I thought there should be a reference to the 32-bit dll in the ftdi-win32 project I could change for a 64-bit dll reference before recompiling everything on a 64-bit system, but I didn't find.
I would greatly appreciate any help about this. I don't feel like I'd find a way around this problem on my own anytime soon. The files I describe can be found in the most recent of these packages.
Thank you very much,
MJ
I finally managed to generate that 64-bit DLL file. ... :)
Here is how I obtained it:
Downloaded the JD2XX package (the most recent is actually dated 20071214).
Downloaded mingw-w64 (personal build sezero) and decompressed it in C:\ (giving C:\mingw64).
Brought some modifications to the JD2XX package.
Adjusted Makefile.conf
Corrected MINGW and JDK paths according to my system.
Selected ftdi-win32 and amd64
Renamed the already generated 32-bit JD2XX.dll file so that make stops telling there is nothing to be done.
Renamed ftdi-win32/libftd2xx.a which is 32-bit... Replaced it by a copy of ftdi-win32/amd64/ftd2xx64.lib (renamed as libftd2xx.a, of course).
Called C:\mingw64\bin\mingw32-make.exe from the main directory of the JD2XX package. This created a new JD2XX.DLL file which allows me to communicate with FTDI devices on my 64-bit computer without having to use a 32-bit JVM.
The generated file for download if anyone needs it.
The "generated file for download" didn't work for me, so I followed the instructions and made it myself, which works:
http://dev.geogebra.org/download/lib/ftdi/JD2XX_64_2.08.17.dll
It also looks like you should be able to build a 64-bit dll on a 32-bit system (or even on linux) by downloading the correct version of mingw-w64:
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/sezero_4.5_20111101/
Also, some of the links are out of date. These are current:
d2xx.svn.sourceforge.net/viewvc/d2xx/trunk/
www.ftdichip.com/Drivers/D2XX.htm