0

I have a program that is running inside eclipse right now and uses a JNI call to a shared object I created as a wrapper for another shared object on the system. This works just fine when I run it from inside eclipse however when I run it from the command line with the following command the shared object that the wrapper calls throws a undefined symbol error.

java -Djava.library.path=[path to library] com.[my name].[program]

ldd does not seem to indicate that any libraries are missing from the shared object. I have also tried setting all the environmental variables in the shell that I execute it the same as the eclipse environment and it does the same thing. Any suggestions on where to go from here are greatly appreciated I am out of ideas.

Thank you for your help

Shawn
  • 3
  • 1

1 Answers1

0

Have you checked the value of the LD_LIBRARY_PATH environment variable?

ChrisJ
  • 5,161
  • 25
  • 20
  • I have added everything to the LD_LIBRARY_PATH in the shell that i am running it from that is in the environment inside eclipse. I got this out of eclipse using System.out.println(System.getenv()) in my program. Is it possible that the program sees a different LD_LIBRARY_PATH from within eclipse somehow? – Shawn Mar 09 '11 at 20:50
  • If you're running Eclipse from the shell in which you checked everything, then I would say no... – ChrisJ Mar 09 '11 at 21:04
  • I am not running Eclipse from the shell but I believe it inherits the execution environment from there and adds a few things. – Shawn Mar 09 '11 at 21:07
  • Hmm, not necessarily. If you modified the environment in the shell, then Eclipse doesn't inherit from it if you run it from a GUI "launcher". Does `System.out.println(System.getenv())` exhibit different values when launched from Eclipse or from the shell? – ChrisJ Mar 09 '11 at 21:10
  • They seem to be mostly similar, I just wrote a run script that sets everything except the X display variable to what eclipse uses before it runs the .class file outside of Java so everything in that regard should be the same. I believe it is something else unrelated to the environment variables in the shell that I run the Java program from. – Shawn Mar 09 '11 at 21:16
  • Exception in thread "AWT-EventQueue-0" java.lang.UnsatisfiedLinkError: [pathtowrapper]/wrapper.so: [path to shared object]libNRSIPS_CUDA.so: undefined symbol: cufftPlan2d – Shawn Mar 09 '11 at 21:27
  • With the command `ldd libNRSIPS_CUDA.so` you should get a list of the libraries `libNRSIPS_CUDA.so` depends on. One of these contains the `cufftPlan2d` symbol. What if you add the path to this one to `LD_LIBRARY_PATH`? I mean, running your program with `LD_LIBRARY_PATH=the_path java ...` – ChrisJ Mar 09 '11 at 21:48
  • So I believe the symbol is in /usr/local/cuda/lib64/lcudart.so.2 so I ran the command LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH java -Djava.library.path=[path to my library] [program] Is this what you meant? Unfortunately it still gives me the same error it did before. – Shawn Mar 09 '11 at 21:58
  • What finally fixed the problem was linking in the cuda fft library into my shared object file via -L/usr/local/cuda/lib64 -lcufft. I have no clue what is different but I am very happy that it works now. – Shawn Mar 09 '11 at 22:08
  • Glad to hear it works now, but the reason it didn't work remains unclear to me... – ChrisJ Mar 10 '11 at 15:13