NDK dlopen 에러 so 파일 로딩

Question

안녕하세요

 

 

먼저 예전에 익명으로 저에게 dlopen 설명해 주신 분께

 

죄송하다는 말씀과 함께 감사의 말씀 드립니다.

 

제가 오해를 했습니다.

 

죄송합니다.

 

 

so 파일을 NDK 에서 dlopen 으로 로딩 하는데

 

제가 만든 so 파일은 로딩이 되는데

 

외부에서 받은 so 파일은 로딩이 안됩니다.

 

 

이부분을(제가 외부 so 라이브러리를 만든것이 아니라서)

 

외부에서 주신 분께 의뢰를 하는게 맞는 거 같습니다.

 

 

제가 따로 so 파일을 로딩이 될수 잇도록 하는 방법은 있는지도 궁금합니다.

 

답변 부탁 드립니다.

 

감사합니다.

Answer 1

dlopen이 안되는 이유는,

1. 경로를 못 찾았거나, so에 read권한이 없어 읽지 못하는 경우

2. 심볼을 못 찾았을 경우

입니다.

경로가 제대로 되어 있다면,

so를 만드는데 사용했던 심볼을 못 찾았을 가능성이 높습니다.

 
심볼을 못 찾는 경우는  예를 들어 liba.so라는 라이브러리가 로그를 위해 liblog.so를 링크해서 만들었다면, liba.so를 dlopen하기 전에  liblog.so가 메모리에 로드되어야 __android_log_print  같은 심볼이 뭔지 알 수 있어 dlopen이 됩니다.

(예를 들어 설명하는 것으로 안드로이드의 경우 liblog.so를 같은 라이브러리는 별도 처리를 안해도 메모리에 사전에 로드 되어 있습니다.)

 

따라서 링크에서 사용하는 라이브러리와 찾지 못하는 심볼을 찾아 내셔서 해당 라이브러리를 System.loadLibrary 전에 System.loadLibrary(해당so)로 먼저 로드하시면 되는데,

nm 이나 strings, objectdump 등으로 심볼을 찾을 수는 있으나.

어떤 symbol를 로드해야 하는지 찾기 쉽지 않으니. 가급적이면 개발자에게 문의하는게 좋으실 듯 합니다.

혹은 so빌드시 A(size_t a) 같은 형식의 심볼을 링크했는데.

안드로이드 버젼 및 컴파일러에 따라 size_t가 long 혹은 int로 각각 다르게 인식하여,

 빌드시는 A(long a) 심볼로 빌드 했는데. 실제 링크하는 라이브러리가  A(int a)로 되어 있어서 로드안될 수도 있습니다.

이 경우는 형식을 맞춰줘야 합니다.

 

마지막으로  N버젼의 경우 openSSL을 비롯한 PDK 라이브러리를 못 쓰게 강제하고 있습니다.

만약 N버젼에서 문제가 된 것이라면,

최악의 경우 해당 라이브러리가 PDK 의존성을 제외하여  재 개발이 되어야 할 수도 있습니다.