JNI 문제, Shared library를 인식하지 못하는 현상
글쓴이: reshout / 작성시간: 금, 2006/02/24 - 9:31오후
JNI를 이용하여 코딩하던 중 개발환경을 바꿨더니 JNI를 사용한 코드에서 shared library를 인식하지 못합니다. 다음과 같은 에러메세지가 출력됩니다.
Quote:
Exception in thread "main" java.lang.UnsatisfiedLinkError: /home/reshout/jni_example/libhello.so: /hom
e/reshout/jni_example/libhello.so: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1751)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1676)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)
at HelloWorld.<clinit>(HelloWorld.java:5)
LD_LIBRARY_PATH가 맞지 않았을때와 분명 다른 에러 메시지 입니다. LD_LIBRARY_PATH 지정이 잘못된 경우는 다음과 같은 에러메세지가 발생하니까요
Quote:
java HelloWorld
Exception in thread "main" java.lang.UnsatisfiedLinkError: no hello in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1682)
at java.lang.Runtime.loadLibrary0(Runtime.java:822)
at java.lang.System.loadLibrary(System.java:992)
at HelloWorld.<clinit>(HelloWorld.java:5)
libhello.so 라는 라이브러리 파일은 분명 LD_LIBRARY_PATH에 존재하는데 파일을 찾을 수 없다고 합니다. :(
동일한 코드가 다른 머신에서는 올바르게 동작합니다. 무엇이 문제일까요?
Forums:
LD_LIBRARY_PATH 를 쓰지 않는 경우가 몇 가지 있습니다.
LD_LIBRARY_PATH 를 쓰지 않는 경우가 몇 가지 있습니다.
1. .so 를 캐싱하는 경우
리눅스와 솔라리스는 공용 so파일을 지정하는 방식을 달리하거나, so 파일을 캐싱하는 기능이 있습니다. 이 경우, 패쓰에 해당하는 디렉토리에 파일이 있어도 읽지 않습니다.
solaris : crle http://www.gunfleet.com/solaris/crle1.htm
linux : ldconfig http://www.die.net/doc/linux/man/man8/ldconfig.8.html
2. AIX
AIX 에선 환경변수명이 LD_LIBRARY_PATH 가 아니라 LIBPATH 입니다.
1번의 경우 해결책은?
LIBPATH로 조정해본 결과 결과가 달라지지 않습니다.
1번의 문제 때문이라면 어떻게 so 파일을 캐싱하는 기능을 해제할 수 있는지 알려주시면 고맙겠습니다. :P
ubuntu linux를 사용 중 입니다.
Re: 1번의 경우 해결책은?
진즉에 실행환경을 올려주셨음 좋았을것을.
ldconfig 명령어로 라이브러리 캐시를 다시 만드세요.
Re: 1번의 경우 해결책은?
ldconfig를 실행해본 결과 시스템 라이브러리만 다시 등록하는 것 같던걸요. 에러메세지는 여전히 마찬가지입니다. 에러메세지에 뻔히 라이브러리 파일명까지 나오는데 없다고 하는 것은 아이러니 하네요 :cry:
shared object 가 필요로 하는 shared object 등이
shared object 가 필요로 하는 shared object 등이 LD_LIBRARY_PATH에 없거나 glibc 등의 version이 맞지 않는 경우도 있습니다.
"ldd libhello.so" 로 필요 라이브러리가 모두 존재하는지 확인이 필요합니다.
코더에서 프로그래머까지
개발 환경이 무엇에서 무엇으로 바뀐 것인가요? 저도 바이너리 버전이 맞지
개발 환경이 무엇에서 무엇으로 바뀐 것인가요? 저도 바이너리 버전이 맞지 않아서 그럴 것 같다는 생각이 들기는 합니다만, 새로 컴파일을 해서는 테스트를 해보셨나요?
----
I paint objects as I think them, not as I see them.
atie's minipage
[quote="hultul"]shared object 가 필요로 하는 s
다음과 같은 메세지가 출력된다면 필요한 라이브러리가 모두 존재하는 것 아닌가요?
개발환경이 바뀌었다면, javah부터 ... 전부 재빌드해보세요.
개발환경이 바뀌었다면, javah부터 ... 전부 재빌드해보세요.
[quote="Anonymous"]개발환경이 바뀌었다면, javah부터
make를 이용해 일련의 과정들을 다 포함시켜 해 오던 것이라 ...
우분투 무슨 버전인지와 위에 ldd로 해서 볼 수 있는 것들 - 즉, 설
우분투 무슨 버전인지와 위에 ldd로 해서 볼 수 있는 것들 - 즉, 설치된 gcc와 libstdc++ 버전 등을 올려 봐 주십시요. 언뜻 봐서는 libstdc++ 버전 낮은 것이 필요한데 높은 것이 불려지는 것이 아닌가 추측합니다.
테스트 프로그램이 간단하면 같이 올려 주시면 답변하시는 분들도 테스트를 직접한 후에 답변을 해 주실 듯 합니다만. 그리고, strace -e open 해서 so가 열려지는 것을 확인해 볼 수도 있지 않을까 싶고요.
----
I paint objects as I think them, not as I see them.
atie's minipage
자문자답
해결했습니다.
모든 문제는 64bit 머신으로 옮겨가면서 발생한 것 입니다.
amd64용 JVM을 설치하니까 문제 없이 바로 되네요.
32bit JVM이 참조할 라이브러리가 없었나봅니다.
답변해주신 모든 분들 감사드립니다 ^^
댓글 달기