Angelin01
commented
4 years ago We have solved this, in a way. Linker wasn't linking properly, so we had to change two things:
In the Java Makefile, we added a LIBS variable that held our paths to the java libs, so it could find files like jni.h. For us, it looks similar to LIBS=-I/usr/lib/jvm/java-13-openjdk/include -I/usr/lib/jvm/java-13-openjdk/include/linux. We then added this variable to the gcc line: gcc $(LIBS) $(NATIVE_C) $(CFLAGS) -o $(NATIVE_SO). If you have these in your default library directory or symlinked in a similar way, this should not be a problem.
Second, and this is the more important part: the linker isn't linking properly. So we added to CFLAGS the linker rpath option for the libdmtx library: CFLAGS=-shared -fpic -Wl,/usr/lib/libdmtx.so. This library may be located elsewhere depending on whether you built it yourself, installed it, downloaded from your favorite package manager, whatever, this is up to you.
After building and properly pointing LD_LIBRARY_PATH to the native folder, it works!
I am trying to use the Java version of this library, however any use attempts have failed with Java not finding the appropriate symbols:
java: symbol lookup error: /home/angelin/git/dmtx-wrappers/java/native/libdmtx.so: undefined symbol: dmtxImageCreate. This is when trying to run either the GUIExample or the CLIExample.I am creating the issue here since the repository seems more active. The wrappers repo hasn't been updated since 2014.
I want to note that Python's wrappers, obtained with pip, are working perfectly fine. I'd also like to note that this will be used in an embedded system later, so compilation is a must, no ready-to-go binaries.