I just developped my first program with JCUDA (on eclipse) and i want to execute it on other machines that don't have the same nvidia-driver and compilers i used to develop it.
How can I export just the executable to another machine and execute it without recompiling the code ?
Any help will be appreciated
(Sorry, this may not fully answer your question if you expected a step-by-step-manual. I'll consider doing some experiments here, and maybe extend this answer or add the information on the website)
For the driver API, the CUDA version on the target system must at least be that of the corresponding JCuda version - otherwise, newer CUDA functions would simply not be supported.
Regarding the runtime libraries, quoting from the CUDA FAQ:
Q: What do I need to distribute my CUDA application?
Applications that use the driver API only need the CUDA driver library ("nvcuda.dll" under Windows), which is included as part of the standard NVIDIA driver install.
Applications that use the runtime API also require the runtime library ("cudart.dll" under Windows), which is included in the CUDA Toolkit. It is permissible to distribute this library with your application under the terms of the End User License Agreement included with the CUDA Toolkit.
So in doubt, you may include the "cudart.dll" that you used for compiling your application into the distribution package.
Newer versions of CUDA also support static linking against the runtime DLL, but this is not (yet?) done for the JCuda runtime library.
Related
Im new to app development and was wondering if it would be possible to include another jdk. For example java 17 and run a jar that needs to be run in this exact version? I think termux has an api that you may use for these purposes but is there another possibility? These jars are only console based and without any gui.
I first tried to use the jar as a android library inside the app, which did not work since it was compiled in java version 17. I tried decompiling the jar and recompiling it with the version I was using. The problem is that all the libraries used are on other versions than I need them to be and so I could not recompile it. I also thought about writing the application in c# but I am not used to it at all, which would throw many new problems that I would be willing to take if it would be a possibility to work out my project.
Q: Is loading the code into your Android application an option?
A: No.
Android loads code from ".dex" files not ".class" files.
The ".class" files would need to be translated using dx.
The Android dx command doesn't understand Java 17 ".class" file format.
Also the code in the JAR is likely to depend on classes in the Java SE class library that the Android doesn't provide.
Q: What about running it in a separate Android VM?
A: No.
An Android VM requires ".dex" files; see above.
Also, the Java SE class library issue; see above.
Q: What about launching an OpenJDK or Oracle Java 17 JVM on the Android device to run the JAR?
A: In theory Yes, but in practice No. As far as I am aware, there is no port of OpenJDK Java SE to the Android OS platform.
Q: What about using Termux?
A: OK ... that might work. See Is it possible to install the JDK on an android device?.
I have no experience with this, and don't know what problems you may run into doing this. But I suspect that you wouldn't be able to distribute something that relies on Termux via the Google Playstore.
Another option is to download the source code1 for the application and try to build it in your Android dev environment
If the code uses Java classes / packages / libraries that are not available for Android, recode the relevant parts of the application to use Android equivalents instead.
Ditto if the code uses Java language features that are not yet supported in Android Java.
It probably won't be easy. It may turn out to be impractical.
1 - You said in a comment that the code your are trying to use is "open source". So the "download source and build it" option is available to you. I'm puzzled why you tried to decompile and recompile it instead ...
I have a PowerMac and it is giving me bad version number on some .jars. I would love to make it seem like I am running Java 6. How would I spoof the version? Let me also say I am running PowerPC and Leopard
The most likely problem is that you have Java 6 JAR files and you are trying to run them on an old Java installation.
How would I spoof the version?
The answer to your question is that you can't. The way to run Java 6 specific JAR files it to use a Java 6 (or later) JRE or JDK.
The problem is that the format of Java class files has changed, and your installation can't cope with the new format. And this is not a gratuitous change that you can pretend doesn't exist. Java 6 (actually Java 5) has support for generic types, enums, annotations and other things. Assuming that the JARs contain code that uses these new language features, an older JRE simply won't know what to do with them.
There are two solutions:
Upgrade your Java installations to the required level on all machines. This is the best solution ... if it is an option ... because it means your users will get the benefit of security and bug fixes and performance enhancements. (And progress of your project won't be held back by the constraint of supporting legacy platforms.)
Compile all of your code for compatibility with the oldest version of Java that you still have to use. Either compile on the corresponding old JDK, or on a more recent JDK using appropriate -source / -target / -Xbootclasspath options ... as described by the javac manual page.
The catch with the second solution is that if the source code for the JAR files in question uses recently added Java language features or APIs, then recompiling for the older platform will fail. To fix this you will need to rewrite your code to replace the nice modern stuff with archaic stuff. Not a good solution, IMO.
The other possibility is that you are seeing corrupted JAR files. This is unlikely, but it can happen if you are using applets or webstart, and the server is delivering error pages instead of JAR files.
The third possibility is that you simply haven't configured your Mac's Java installation's correctly. Making Java 7 the default should allow you to run everything without class version problems. (Thanks #paulsm4) Note that I can't help you with that ... 'cos I don't use Java on a Mac.
I'm writing a program with Java7 and JavaFX2, but I'll need to show it to people who only have access to machines with Java 6 installed (with no JavaFX).
Is there any way I can find a solution to this short of asking them to install Java7 and JavaFX2?
Perhaps you can create a self-contained application package by "bundling" your program with Java 7 and JavaFX 2. That way you don't have to worry about what's on or not on your user's machine.
You can read more about self-contained application packaging at http://docs.oracle.com/javafx/2/deployment/self-contained-packaging.htm.
Theoretically yes, but you have to check if that is conform to the license conditions of Sun/Oracle the owner of JavaFX:
You could sue tools like http://one-jar.sourceforge.net/
They pack all your java into one jar.
Another possibility you could obfuscate your application and include JavaFX.
But this, too might violate the license conditions.
Both solutions might be more work, than the effort off installing JavaFX to the (one)clients computer.
Try JavaFX2 for JavaSE6
On page: http://www.oracle.com/technetwork/java/javafx/downloads/index.html
Download Download JavaFX 2.2.3 for Java SE 6 ...
If you are using Eclipse JDT, you can configure your projects "Java Compiler", by "Enable project specific settings", to "Compiler compliance level" value 1.6. This should produce bytecode in a version suitable for Java 1.6 VM. I suppose, but am not sure, that Eclipse shall also warn you if you use library elements not present in the 1.6 library version; though you can be careful about that with or without warnings. As with the previous solutions, JavaFX you can just package in your application's JAR if the license agreement allows it.
Is eclipse platform independent?
As per my knowledge, eclipse is written in java. If it is so eclipse should be platform independent. But there are different eclipse for different OS???
No, you need to download a platform specific version because of SWT which accesses the native GUI libraries of the operating system using JNI. Note that Eclipse provides versions for most platforms (see for example All Platforms for the Eclipse SDK 3.5.1).
There are distributions of Eclipse for most Intel/AMD based platforms and for major UNIXs.
You are also supposed to be able to compile and build it yourself on other platforms.
The differences stem primarily from three issues:
1) Availability of needed Java distribution on the platform (e.g., late introduction of newer Java versions on Mac).
2) 32bit vs. 64bit
3) Underlying UI toolkit
While Eclipse can run under Swing, it may look like crap and perform pretty badly.
People often expect more from the IDE, so the SWT can use some native widgets. Some plug-ins also need more direct access to the graphic subsystem. This, there are specific distributions of Eclipse that use specific platform graphic infrastructure. The most notable example is again Mac OS, where there was initially a version for Carbon, but only much later did a Cocoa version show up.
Most OS should support Eclipse. As long as it supports Java and SWT
If it is 100% java-based application, yes it will be platform independent. The problem is some code of Eclipse is not Java, so it's obvious that because of this code, Eclipse is not 100% platform independent. You can however just change that particular native jars with the suitable jars for your platform and Eclipse will then run correctly.
I'm writing a desktop app using JOGL, and deploying on Win/Mac/Linux. On Linux we find that the OpenGL libraries installed are not always up to the job, and we need to have the capability of switching our own software emulation OpenGL in. Naturally we expected that we could place out libraries after /usr/lib or before /usr/lib to favour ours or the default.
It turns out that ours are picked up preferentially by JOGL. Does anyone know if the JOGl libraries do special processing looking for libGL etc, favouring perhaps a later version over an earlier? Any information welcome.
I assume that the Java side of JOGL uses JNI (Java Native Interface) to interface with the native libraries. JNI uses ths Java system variable java.library.path to find native libraries. You could set it on the command line using the -D switch when running your Java app:
java -Djava.library.path=/some/path mypackage.MyProgram
It could also be that the native system doesn't pick up the right OpenGL libraries itself. On Linux, you can set the environment variable LD_LIBRARY_PATH to specify where Linux should look for shared libraries. This page explains more (see section 3.3.1).
Note that you can get the source code of JOGL on the JOGL homepage, so if you really want to know, you could download it and start digging into it.
(why is there a stupid limitation "new users can only post one hyperlink"????)