Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Java wrappers can't load library #36

Open
Angelin01 opened this issue May 5, 2020 · 1 comment
Open

Java wrappers can't load library #36

Angelin01 opened this issue May 5, 2020 · 1 comment

Comments

@Angelin01
Copy link

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.

@Angelin01
Copy link
Author

Angelin01 commented May 11, 2020

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant