The most optimized implementation of Ed25519 (http://ed25519.cr.yp.to/) contains both C and assembly code. As my program is implemented in JAVA, I would like to generate a shared library (.so) for Ed25519 but failed. This is most probably because Ed25519 assembly code does not support -fPIC (If i was wrong pls point out).
It seems that JDK 8 can support the static linking (Linking static library with JNI), but there is no example I can found online. I tried to generate a static library (.a) and simply load it as a shared library by JNI, but obviously JAVA can not accept it.
So in practice how can I link and load a static library to my JAVA program?
OK, now I have statically integrated ED25519 with my Java program. I believe the solution can be easily applied to other cases in which shared library can not be generated.
Basically, I implement a wrapper in C, which :
invokes JNI interface 'JNI_CreateJavaVM' to launch a JVM, say, my_jvm;
in my_jvm, registers each native method defined in java code with the corresponding method implemented in static library, by JNI interface 'RegisterNatives' (may needs a glue program in this step);
launches java code in my_jvm, e.g., by JNI interface 'CallStaticVoidMethod'.
The wrapper is linked with the static library (ED25519.a in my case) by GCC. My java program is launched through the wrapper.
Then, the native methods in Java can locate and invoke the methods in C library.
Related
I'm trying to setup the files from LuaBinaries (specifically Lua 5.2.4 64-bit), and there are a few things I'm confused about.
There are two zip files provided, the binaries: lua-*_Win*_bin.zip and the libraries: lua-*_Win*_*_lib.zip
So, these are my questions:
For the libraries, two versions are provided, static and dynamic. What's the difference?
The zip file for the dynamic libraries contains a lua*.dll, but a file with the same name is provided in the zip file for the binaries. Which one should I use?
Some of the library zip files (the older ones?) contains a liblua*.a file, is this supposed to be a misnamed lua*.lib file?
For the libraries, two versions are provided, static and dynamic. What's the difference?
The static library can be embedded into your own program. While the dynamic library is linked to your program, so the system will search for it when running your program. If the search for the dynamic library failed, the system won't be able to run your program correctly.
The zip file for the dynamic libraries contains a lua*.dll, but a file with the same name is provided in the zip file for the binaries. Which one should I use?
The lua*.dll under lua-*_Win*_bin.zip is the dynamic link library(.dll) used by lua.exe and luac.exe. An error will be thrown by Windows if you run lua.exe after deleting it.
Which one should you use? It depends on your purpose. Usually you want to use the static library in you project.
Running different versions of Lua bytecode (e.g., runs the bytecode created by luac v5.1.4 with lua v5.2.4) is forbidden (by checking the header of bytecode files).
Lua sometimes brings breaking changes upon upgrading, and some public APIs vary between different versions. If you build and install Lua from source code, only the binaries and the static library are produced.
Lua is a very tiny language (the static library under Linux is about 356K(v5.1.4) or 440K(v5.3.3), measured by du -sh liblua.a), so embedding the static library with your program is fine for many high-end devices.
If you feel familiar with make command, you can build Lua from source code and load it into your project. Or, just use the static library in your project. (I don't think most Windows users have a lua*.dll in their enviroment.)
Some of the library zip files (the older ones?) contains a liblua*.a file, is this supposed to be a misnamed lua*.lib file?
No, the libxxx.a and libxxx.so is the static and dynamic library naming conventions under *nix systems, like Linux and FreeBSD.
I'm compiling c++ to web assembly using clang --target=wasm32 --no-standard-libraries. Is there a way to convince clang to generate sqrt? It's not finding <math.h> with this target.
Do you already tried to compile without the flag --no-standard-libraries? If you remove it, the clang probably will find math.h library (because its a standard library).
This is because wasm32-unknown-unknown is a completely barebones targets in Clang, and doesn't have any standard library - that is, no math.h, no I/O functions, not even memcpy.
However, you can usually get away with using --target wasm32-wasi + WASI SDK instead: https://github.com/WebAssembly/wasi-sdk
It includes the whole standard library, including even functions for interacting with the filesystem via the WASI standard in compatible environments.
If your code doesn't depend on filesystem / clock / other I/O, then you can safely use WASI-SDK to get math.h, memcpy, malloc and other standard functions, and the resulting WebAssembly will be compatible with any non-WASI environments as well.
GraalVM native-image allow us to convert Java libraries into local executable. It also allow to compile to shared library as mentioned https://www.graalvm.org/docs/Native-Image/user/README
An native image can be built as a standalone executable, which is the
default, or as a shared library by passing --shared to native-image.
For an image to be useful, it needs to have at least one entry point
method.
The closest thread I found is this one https://github.com/oracle/graal/issues/373, but still can't find any guide to do so for iOS, is that possible? Any guide I can follow?
I have written a c++ library that needs opencv which is an image processing library. I want to now use this c++ library on ios. To do that I am going to copy my code to a mac and build to produce a cocoa touch static library.
Since, this has a dependency on opencv, I downloaded its ios framework. But now I am confused whether a framework can be used from c++ code or just from objective c/c++ ? Do I have to recompile this library so that i get c++ libraries or I can use the framework in my c++ code?
Yes, it can be used with c++. You will have to make sure you Type is set to "Objective C++ Source" for where you are making the framework calls.
I mix my C++ code with frameworks all the time.
Note this goes both ways. If you have Obj-C interacting with C++, you'll need to either have the file be a .mm or be of the "Objective C++ Source" Type.
The Type selection is in the File Inspector for files.
I've tried to formulate the problem in an abstract way, but anyway I give details about the actual libraries in the end.
Dynamic library Addon is statically linked against other library WebRTC which has some code in assembly and this code is linked into WebRTC as object files together with WebRTC's own object files. Lets call this assembly code VP8. Functions of VP8 are marked extern inside WebRTC. Some function Encode() from Addon calls functions of WebRTC which eventually calls functions from VP8.
Now, the application Firefox which is going to load library Addon is quite complex and has its own version (means statically linked) of library WebRTC(let's call it WebRTC2), but an older one.
So, here is a problem: if a call of Encode() is made from the application Firefox, WebRTC functions get called (not WebRTC2, which is correct) BUT when WebRTC tries to call VP8 functions, they get called from the WebRTC2 version (means application's version of WebRTC), but not from WebRTC.
Is there are way to force WebRTC make calls only from local copy of VP8?
Application Firefox is a Firefox browser, WebRTC is a WebRTC library, VP8 is a VP8 codec library (inside WebRTC) and Addon is my Firefox C++ add-on.
UPDATE - DETAILED DESCRIPTION
Here is "unabstract" description of the problem:
So there is a C++ XPCOM add-on which is statically linked against latest version of WebRTC library.
At some point inside add-on a call for encoding a frame is made (method Encode of VP8Encoder class) and it crashes in Firefox all the time, while continue to work well on test programs using gtest framework.
The problem is that at some point inside WebRTC there is VP8 assembly code which is get called for encoding and functions of this assembly code are declared as extern in implementation files. Actually, it crashes on vp8_intra_pred_y_ve_sse2 function.
I've compared three assembly codes of this function: one is from my version of WebRTC (used in add-on), second - where debugger crashed and the third one - from source code of Mozilla's WebRTC.
It turned out that for some weird reason, Mozilla's code get called instead of add-on's WebRTC (they both have same names of course) and as Mozilla's WebRTC code is outdated, it crashes with EXC_BAD_ACCESS.
This probably won't be much help to you, but since no one else has responded, here I go ...
You didn't mention if you're running on Linux, Windows, or something else. My answer is for Linux. I believe Windows loads dynamic libraries differently.
I think what's happening is that you've statically linked against the WebRTC library stub interfaces and those stub interfaces are dynamically linking to the actual implementation, and then getting the first instance of the WebRTC library loaded into firefox instead of the second. Be sure that you're really linking against a statically compiled version of the WebRTC library.
The linux dlopen(3) man page has an interesting flag listed that seems like it would help if your library was the one loading the WebRTC library:
void *dlopen(const char *filename, int flag);
dlopen()
The function dlopen() loads the dynamic library file named by the null-
terminated string filename and returns an opaque "handle" for the
dynamic library. [...]
RTLD_DEEPBIND (since glibc 2.3.4)
Place the lookup scope of the symbols in this library ahead of
the global scope. This means that a self-contained library will
use its own symbols in preference to global symbols with the
same name contained in libraries that have already been loaded.
This flag is not specified in POSIX.1-2001.
Unfortunately, firefox is the one loading your library.
If your library was dynamically linked against WebRTC (which it seems to be) and you explicitly loaded the WebRTC library you want using dl_open() with the RTLD_DEEPBIND flag, than that would solve your problem.
This won't help you much since its not your code that's binding to vp8_intra_pred_y_ve_sse2, but its worth pointing out that gcc also has the dlsym() function which can take a couple of special flags:
void *dlsym(void *handle, const char *symbol);
dlsym()
The function dlsym() takes a "handle" of a dynamic library returned by
dlopen() and the null-terminated symbol name, returning the address
where that symbol is loaded into memory. [...]
There are two special pseudo-handles, RTLD_DEFAULT and RTLD_NEXT. The
former will find the first occurrence of the desired symbol using the
default library search order. The latter will find the next occurrence
of a function in the search order after the current library. This
allows one to provide a wrapper around a function in another shared
library.
You could use that in your code to at least debug what's going on by having it print out the values it gets for a lookup of vp8_intra_pred_y_ve_sse2.
Finally, the same man page notes that linux has a dlvsm() that takes a version string argument as well, allowing the XPCOM code to specify which version of the function it wants:
#define _GNU_SOURCE /* See feature_test_macros(7) */
#include <dlfcn.h>
void *dlvsym(void *handle, char *symbol, char *version);
If it were me, and I was forced to dynamically link the stuff, I'd go with the brute force approach. Go into the libraries and change the function names (in both libraries). Its not elegant, and it will be a headache whenever a new version of either library comes out, but its simple and direct.