I have well-working simple android app(graphically does nothing, but calculates some data), that uses native libraries, those libraries is for x86, so I am hoping to make that code work under x86 ubuntu as a simple compiled java binary.
So after finding all library dependencies compiler tells me:
Exception in thread "main" java.lang.UnsatisfiedLinkError:
lib/libgnustl_shared.so: lib/libgnustl_shared.so: undefined symbol: __sF
After a bit googling I found that __sF is some kind of android specified parameters array, that accesible in the android env(or elsewhere, I actually don't know).
libgnustl_shared.so depends from libm.so and libdl.so, that comes with ubuntu.
Should I try to find android x86 libm.so and libdl.so? Or try to implement some how __sF in java code?
(main point is to solve issue with libgnustl_shared.so, other libraries is written manually by my co-worker so I dont expect any harm from them)
I hope someone has the sacred knowledge to help me make it work. Appreciate any help.
Related
How is the java utility that begins the process of launching a class told to "spill its guts" on what it's doing as it tries to load classes?
In particular, what file paths is it TRYING to access, only to perhaps discover whatever it's looking for is not there, at least as it interprets the specification given? There was a way to get that information, but I can't find it now.
Note that this is Java version "1.8.0_333" on Windows 10.
I've tried every flag known to me, via the -h and -X flags, and I strongly suspect what I'm looking for is (was) an X flag that's been removed, just as the -X help output warns. And so, there must be an OS way to figure this out, I sure hope!
You might ask why? Whatever for? What are you trying to do? Well, that's the bulk of this question's text. To wit:
As one of the very early users of Java (I started with 1.1) way back in the '90s, I had an issue moving an application suite I'd written for my company on Linux to MS Windows and I got it working by using Cygwin. Along the way, this same sort of issue came up and I quite vividly recall having found a mechanism for getting the Java launcher to articulate just what file specifications - paths - it was actually using in searching for the appropriate class. And through using this, I found that the CLASSPATH was being specified incorrectly, and with some experimentation, I got it working reliably. Now I need to do that again!
This flag I'd used was immensely helpful in figuring out just what the file specification format CLASSPATH needed to be (we're not talking semicolons here) this combination of OS, Java, and Cygwin. After some hours of what I hope was reasonable hunting, I'm wondering if this capability has been removed at some point? Either that or "I'm looking for the wrong thing." Heck, since the source is available (I think!), maybe some brave soul has hacked the java utility to do such a thing?
It may help to understand that for this application I wrote for my company, it was a major goal to have the source work pretty much the same on all Windows and Linux / Unix systems (and at the time, macOS), and just use a configuration file to tell the code what's different. And that wasn't easy to figure out, but with this flag, it wasn't that hard, either.
But, unfortunately, I haven't needed this knowledge since I figured it all out all those years ago, and apparently, this little kernel of knowledge is very hard to find today. Or, it's no longer pertinent to the modern version(s).
I don't think this has anything much to do with the actual problem, but it may help in people's thinking if they understood the scenario: The current situation is that I have a fully functional installation of this software on Windows 7 to use as a comparison for how to configure things on Windows 10 (and hopefully younger). The Windows 7 is running a pretty modern Cygwin installation and very nearly the most modern Java - just a sub-version away from the new installation from last week on a Windows 10 box. (Everything's bright and shiny new on the new box.)
The required format for CLASSPATH on the nearly identical but fully functional Windows 7 system is:
CLASSPATH="C:/opt/OurInstallationDir/lib"
And that's it.
This value is picked up in several places as the code later needs to launch Java itself to do some unusual things. However, the java command that gets it all going is launched from a C program - not that that matters for this problem - but the C program (compiled under Cygwin, but perfectly runnable from any Windows environment) helps ensure that the Java environment is secured (policy file contents and so forth) before getting into Java, else it refuses. And this program on Windows 11 launches Java just fine, it's just giving it a CLASSPATH that isn't useful, apparently, even though the files are there where they should be, etc.
Configuring things as before just doesn't work, even from the command line. No version of specifying CLASSPATH seems to work if it's more than a dot; the only thing that works, is being in the /lib directory when starting and using "-cp ." ... But that's just not going to fly for so many reasons! To be a little more clear, I've tried reversing the slashes, using /cygdrive/c/, and whatever else I could think of. But, at least we know that if you're in the directory and use -cp, it will find and launch the program. So, there's nothing wrong with the Java, just pointing the java utility at it.
Again: How is the java utility that begins the process of launching a class told to "spill its guts" on what it's doing as it's trying to load classes?
You use this construct on the JVM:
java -XX:+TraceClassPaths -cp "C:\opt\SomeDirectory\lib" myClass
I was able to get confirmation of what Java was using, not only for my CLASSPATH, but "internally" by using the above.
The fact that it echoed back both what I was doing and what it was doing somehow gave me the insight to check everything about it. Java itself doesn't work (at all) if it's installed in a location that it thinks has a link in it, and it's own fetches go right back to the system disk specification.
From that I found that Java on Windows won't take a CLASSPATH that has a link in it!
Simply ensuring that the whole tree was specified "from the top" of the drive it's on works. If it's not, it won't.
It's now working happily using the syntax noted above.
This is quite different from every other application I've seen on Windows. But, well, it's Java!
This really came from a pointer from Mark Rotteveel who commented above about this article: How to track when class is loaded and destroyed in jvm? And therein I learned how to get the list of all the options the presently in-use JVM supports. All Java developers should be aware of this in my opinion, so thanks to Mark for that.
I would like to load an op from tf.contrib, specifically "_beam_search_ops". I use Tensorflow 1.6 from Maven.
Following the answer at Issue while loading/serving tensorflow model in java using estimators , I'm able to do so on Ubuntu 17.10.
The code looks like so:
TensorFlow.loadLibrary("_beam_search_ops.so");
Then I try to do the same in Windows 10 with code
TensorFlow.loadLibrary("_beam_search_ops.dll");
And it fails with
java.lang.UnsatisfiedLinkError: D:\Users\ALEXAN~1\AppData\Local\Temp\deep_api_plugin\_beam_search_ops.dll not found
at org.tensorflow.TensorFlow.loadLibrary(TensorFlow.java:47)
So what is the reason for this?
While I was writing and researching the question, I've stumbled on the solution.
In order to resolve the problem, a _pywrap_tensorflow_internal.pyd file should be copied to the folder where _beam_search_ops.dll resides. I understand that this is also some kind of dll, but do not understand why it is necessary for Windows and not for Ubuntu. If anyone happens to know, please enlighten me.
Also I understand that this sort of additional information should be provided in a comment to the original answer, but unfortunately I do not have enough reputation to comment and thought this answer could help someone.
Edit: I was too quick to celebrate. With this answer a library is loaded without exception, but the model cannot seem to use it, failing with
Exception in thread "main" org.tensorflow.TensorFlowException: Op type not registered 'GatherTree' in binary running on DESKTOP-EB6GIDR. Make sure the Op and Kernel are registered in the binary running in this process.
at org.tensorflow.SavedModelBundle.load(Native Method)
at org.tensorflow.SavedModelBundle.load(SavedModelBundle.java:39)
Search for answer should continue.
I am using the javax.comm API to help my program communicate with hardware over serial port. I am using the Windows 7 and NetBeans IDE 9.
I used the common Java program to check the available ports on my PC. The program compiled and ran without error. However it returned nothing.
What can I do to use the javax.comm API on Windows? It seems win32com.dll does not work with a 64-bit operating system.
This is how I got it to work.
I've tested it using JDK 1.6 (32bit) on my Windows 7 64bit machine.
Install 32bit JDK.
Copy 'win32com.dll' to JDK_HOME\jre\bin.
Copy 'javax.comm.properties'to to JDK_HOME\jre\lib.
Copy 'comm.jar'to to JDK_HOME\jre\lib\ext.
Now run your program and it should work.
Recent 2.2pre versions of RXTX include binaries for 64-bit windows. I think the latest RXTX information source has changed to this: http://rxtx.qbang.org instead of http://www.rxtx.org though.
At one point the RXTX library included drop-in support for using the javax.comm api. I'm not sure if it still does, but the main change then to use the "native" RXTX packaging was primarily just a package name change.
it seem the win32com.dll does not work with 64-bit Operating system
I think that is correct. In fact, according to the relevant download page, Oracle no longer supports the javax.comm API for any Windows platform.
However, I found this page which has a 64bit build of the DLL, among other things.
EDIT
By an astounding piece of research (i.e. following the links and reading stuff) I found the download page for the latest RXTX, which claims to have binaries for various platforms. If your platform is not there, try building from source. If that doesn't work, consider investing the effort in making it work.
I've integrated RXTX libraries into some of my earlier projects and i found out this bug it has while working with comm ports under windows, so you might want to check this first before going into some serious app design.
Communication works fine, never had any problem with that, but once you open the port you cannot close it and reopen, if you use method provided for closing port, your app just hangs, no exception no nothing. I found later the same behavior described by users on web, but never really found the solution to this problem.
Again, this might help you save some time, check it first.
Latest release, which is this http://rxtx.qbang.org/pub/rxtx/rxtx-2.1-7-bins-r2.zip, doesn't have this issue no more. Unfortunately i think its solved only for windows, its still there on Linux binaries, and i haven't tried it on mac.
Have you got a look on RXTX ? I think it is still active.
I had this issue...on a 64 bit machine..running windows 7
a legacy application developed in jdk 1.4, for 32 bit windows... and using the win32 comm api binary
i tried the RXTX binary for 64 bit and i was able to communicate with my device on some level... but... there were other problems as my application referenced a version of the jpos library that internally was using the comm-api (had import javax.comm.*... in some Serial...Listener class)....
I installed a 32 bit jdk and setup the comm-api binaries for 32 bit windows as directed here...setup comm api on windows
all was fine afterwards
You might be interested at an alternative library I've authored: http://code.google.com/p/jperipheral/
How to get NetBeans to recognize that I have the ACM libraries installed on my computer? I've copied/pasted it into several locations, but always get the same error (basically saying that the package doesn't exist). I've read on a few sites there is a java archive ("jar") file involved, but I don't know if I have it, how to create it if I don't, or where to install/copy it if I do.
As far as details go, I have a PC running Windows 7, JRE 7, and jdk1.7.0_21. I have a "64-bit" computer, if that means anything (I know what a bit is but have no idea whether it would affect Java or NetBeans). The error rears its ugly head when I try "import acm.graphics.*;" and similar statements. The full error message is: "package acm.graphics does not exist".
I'm fairly new to NetBeans and I'm thinking it's probably something simple, and it would really be great to be able to use the ACM libs, so any ideas for fixing the problem would be most appreciated. Thanks.
Several random customers get this exception every time I update my Android app. I've narrowed it down to two reasons, both related to using the jni.
The *.so library is deleted when the app is upgraded.
The *.so library is not upgraded when the app is upgraded, and the old version still remains.
The device reports do not signal that this issue is related to the OS version, memory, or anything rational. Rather than focus on why Android is having trouble upgrading the libraries, I'm hoping someone out there knows how to manually pull the libraries out of the app's APK and put them in the right directory when this error is encountered.
Seems like you probably have an ABI mismatch - or possibly a false ABI mismatch caused by an Android bug that people have been talking about, where a generic arm library may not be accepted when one of the specialized varieties is preferred.
As for your workaround... you cannot write to the lib/ directory of your app's installation, though you can put a library elsewhere if you use System.load() with a precise path/filename instead of loadLibrary() with just a library name. I don't think there's any official (as in future-proof) way to extract arbitrary contents from your apk, though it's fairly easy to do at present with the zipfile classes (with something perhaps such as Context.getPackageCodePath() to discover the location and installation-variable name of the apk)
Checking for the success of the library loading attempt and reporting information about the device if it fails might be as useful.