현상은 조금 깁니다. 크롬 관련된 기술을 컴파일할 경우가 있었는데 이게 Android 소스를 컴파일 하는 환경이 Ubuntu 에서만 테스트 되어 있다는 것입니다. 이런 경우는 OS 까지 개발툴 영역으로 보고 OS 환경까지 맞춰서 개발하는 것이 정신 건강상 좋다는 것을 여러번 겪었습니다. 

소스를 받고 안드로이드 개발환경을 세팅을 하니 20기가로 할당했던 하드가 부족해서 컴파일이 안되는 현상이 나오는 것입니다. (사실 그전에 소스 개발하니 메모리가 부족해서 다급히 cpu 1개랑 메모리를 증설해줬습니다. 이 모든 것이 VMWare 로 하니 편하긴 하더군요) 메모리랑 씨피유랑 달리 하드는 크기를 늘려준다고 해도 (20G 에서 40G 로 증설) Guest OS 가 바로 인식은 못합니다.  따라서 다른 방법을 써야하는데 추천드리는 방법은 

GParted (http://sourceforge.net/projects/gparted/

입니다.  위 링크에서 iso 를 다운받고 VMWare 로 부팅할때 저 이미지로 부팅하게 해 줍니다. 그리고 나서 GUI 버젼에 기본적인 물음에 디폴트 대답을 해주면 바탕화면에 있는 아이콘을 클릭해서 프로그램을 구동시켜주고 나면 

 
이와 같은 화면이 나올것입니다. 이때 이 화면을 저장하고 그 것을 보면서

1. 화면상에 보이는 /dev/sda5 를 지우고 /dev/sda2 를 지웁니다. 

2. /dev/sda1 의 크기를 늘려줍니다. (이때 linux-swap 을 위한 공간 제 경우에는 1024 Mib 를 남겨둡니다)

3. 두번째 확장 파티션을 만들고 그 안에다 linux-swap 파티션을 추가해줍니다.

4. apply 버튼을 눌러서 변경사항을 적용해줍니다.



약간의 시간이 지나면 성공적으로 늘어난 것을 확인하실 수 있습니다. 그리고 다시 리눅스로 부팅하시면 작업 성공 입니다.  
공짜라고 신나서 Maverick (OSX 10.9) 으로 업그레이드 한 후에 XCode 도 5.0.1 로 업그레이드 했습니다. 그러면 당연히 'Command Line Tools' 를 깔아야지 후훗! 하고 깔아줬습니다. 문제가 발생하더군요 gcc-lvm 이 이번 버젼에서는 포함이 안되어 있더군요. 평소라면 언젠가는 업데이트 되겠지.. 하는 마음으로 느긋하게 기다리겠지만 산더미 처럼 쌓아져 있는 일이 제 마음을 압박하더군요. 

주로 작업하는 일들이 open source 를 이용하는 작업들이라 gcc 가 안되면 심각한 문제가 발생합니다. 

$ xcode-select --install


하면 나오는 팝업창에서 '설치' - '동의' 누르면 설치됩니다. 이게 설치가 되면 brew 를 이용해서 apple-gcc42 버젼을 설치해줍니다. 4.2 버젼인게 마음에 걸리지만.. 그래도 작업은 해야 하지 않겠습니까? 

$ brew tap homebrew/dupes
$ brew install apple-gcc42



$ sudo mv /usr/bin/gcc /usr/bin/gcc.old
$ sudo ln -s /usr/local/bin/gcc-4.2 /usr/bin/gcc


자 이렇게 해주면 gcc 를 이용할 수 있게 됩니다. 무려 4시간의 삽질끝에 얻어낸 결과 입니다. 흑흑 
   



원작을 소설로 먼저 접하고 영화로 다시 보게 되면 소설보다 감동이 덜 한 경우가 많습니다. 몰입감에서 차이가 나기 때문이라고 보는데요. 그 차이는 일정 시간안에 느끼는 정보의 양의 차이일 것입니다. 정해진 시간안에 상황을 다 이해해야 하는 영화와 달리 영화보다는 천천히 글을 읽어가며 자신의 상상을 보탤 수 있는 소설의 경우가 몰입감이 더 뛰어날 수밖에 없다고 봅니다. 상상은 (또는 망상까지도) 언제나 빛이 나는법이니까요 

그런 의미로 보자면 게임은 정말 지대한 몰입감을 줍니다. 일단 자신이 진행을 하기 때문에 정보를 받아들이는 속도를 조절할 수가 있고 만약 실패한다고 해도 세이브-로드 라는 방법으로 진행 속도 조절뿐 아니라 필요한 부분에 대해서 자세히 진행을 반복할 수가 있습니다. 그렇기 때문에 잘 만들어진 게임이 주는 감동은 대작 영화나 소설과는 다른 의미로 큽니다. 

파이널 판타지 9은 제가 젊은(?) 시절에 즐겼던 게임입니다. 그 때는 주인공의 강력한 의지와 여유, 마지막 엔딩의 감동등이 대단했던 게임으로 기억하는데 다시 플레이를 해보니 그것과는 별개로 다루고 있는 주제 의식이 잘 다가오더군요. 물론 어릴 때보다 '영어실력이 늘긴 늘었나' 라는 생각이 듭니다. 

갑자기 다시 플레이 하게 된 이유는 별거 아니라.. 

얼마전 우연히 파이널 판타지 시리즈중에서 인기순위를 보게 됐습니다. 


그런데 제가 정말 좋아하던 9편 (IX) 이 인기 순위에서 7위더군요. -ㅅ- 갑자기 치밀어 오르는 분노를 금할 길이 없어서 안드로이드 에뮬로 다시 한번 플레이 시작했습니다. (안드로이드에서 에뮬로 플레이스테이션 게임 즐기는 방법)


 긴 시간동안 플레이하고 점점 엔딩을 향해갈 때 지탄이 '리파의 나무'에서 가넷과 헤어지기 전에 무릎을 꿇더니 '가넷, 아니 공주님..' 으로 시작하는 대사부분은 정말 찌잉~ 하고 감동이 증폭되더군요. (소년이여 여행을 떠날지여다!!) 

  게다가 엔딩에서 회색으로 올라가는 비비의 독백부분은 정말 그 정점으로 치닫더군요. 

  내가 누구인가, 어떻게 태어났는가, 왜 내가 태어났는가 보다는 이미 태어났기 때문에 앞으로 살아가야 하는 날이 중요하다. 그러니 '추억'을 사람들과 공유하며 서로 서로 사랑하라는 메시지를 전한다고 봅니다. 이 주제는 제가 젊을 때 느껴보지 못했던 주제로 이 파이널 판타지 9을 정말 다른 작품들과는 다른 수준으로 만들어주는 주제 의식입니다. 

마지막으로 파이널 판타지 랜드 에 공략을 올리시는 nemi 님이 해석하신 마지막 비비의 독백부분입니다. (출처: 클릭 ) 영문판은 어감상 살짝 다른 느낌이지만 이 정도 해석이면 원작이 주는 느낌을 최대한 살린 것이라 평가합니다!!


  매일 지탄 얘기를 했어...

  우리에게 정말 소중한 사람이 있었다고...

  산다는 것의 위대함을 가르쳐 준 사람이라고...

  

  산다는 것은 영원의 생명을 누리는 건 아니라고...

  그렇게 가르쳐 줬었지?

  서로 도우며 살아가지 않으면 의미가 없다고...


  
  헤어짐은 결코 슬픈 것만은 아닌 거지?

  서로 멀리 있어도 마음만은 통했었잖아?

  그런 소중한 것을 가르쳐 줬었지?



  내가 무엇을 하기 위해 태어난 것인지...

  내가 대체 뭘 하면서 살아가고 싶었는지...

  그런 것에 대해 생각할 시간을 줘서 고마워.


  
  자기가 하고 싶은 것만 계속 하는건

  실은 정말 어려운 일이지...

  모두들... 정말 훌륭했다고 생각해...



  고독을 느꼈을 때 어떻게 해야 좋을지는

  그것만은 배울 수 없었어...

  진정한 대답을 발견할 수 있는 건

  분명 나 자신 뿐일지도 몰라. 그렇지...?



  나, 여러분과 만날 수 있어서 정말 기뻤어...

  좀 더 같이 모험하고 싶었어...

  하지만 이별의 순간은... 반드시 찾아오는 거지, 그렇지?



  모두들... 고마워...

  안 녕...

  내 기억을 하늘에 맡기러 가...


  오픈소스를 만지작 거리다 보면 남의 소스를 볼 일이 무지하게 많습니다. 가장 최근만 해도 이동통신 관련한 소스를 줄기차게 보고 있는데 (지금까지 본것중에서 난이도가 openssl 에 필적합니다.) 이러한 소스는 보통 여러 사람이 몇년동안 작업을 한 것이 대부분 이기 때문에 처음부터 전부 이해하려고 하다보면 들어가는 시간이 엄청 걸립니다. 단기간에 필요한 부분만 꺼내서 이용할 수 있는 신공을 익혀야만 제대로 쓸 수가 있다는 이야깁니다. 이러한 오픈소스 (그 중에서 특히 C 로 만들어진) 들이 어려운 이유가 몇가지가 있습니다. 그중에서 개인적으로 어렵게 만드는 요인이라고 볼 수 있는 것 몇가지만 이야기 해 볼까 합니다. 

  1. 엄청 많은 매크로 
     
     코드를 이해하는 것만큼 이 엄청난 수의 매크로도 이해해야 합니다. 

  2. 핸들러(handler)로 표현되는 다양한 함수 포인터 (Function Pointer)
     
    왜 C 로 C++ 형식처럼 짜는지 대충 이해가 갑니다만 (속도를 위해서겠지요..) static 키워드를 이용해서 C를 마치 OOP 처럼 구현해 놨습니다. 물론 이해하기는 OOP 보다 어렵습니다. (OOP 도 남의 소스는 보기가 쉽지 않지요) 다양한 구조체와 이에 연관된 함수 포인터를 마치 멤버 함수처럼 이용하는 형식으로 구현했기 때문에 추적하기도 쉽지가 않고 어디서 어떻게 불리는 지 파악도 어렵습니다. 


  이 외에도 몇가지는 있겠지만 제가 느끼기에는 이것들이 중요한 요인입니다. 그렇다고 해도 소스를 못 따라갈 정도는 아니지만 일일이 따라가기에는 너무나 방대한 양이기에 제대로 추적하기가 쉽지가 않습니다. 

  그래서 이러한 오픈소스를 분석하거나 자신이 필요한 기능을 추출할 때 쓸만한 팁을 드릴까 합니다. 사실 팁이라고 할만한 것도 아닐 수 있습니다. 일단 '돌아가는 소스를 받아서 구동시켜야 한다' 가 전제가 되어야 하며 이 때 돌아가는 '흐름'을 추적해야 합니다. 너무 난해할 수도 있는데 세부적인 것을 다 파고 들어가는 것이 아니라 필요한 기능이 어떻게 흘러가는지 전체적인 흐름을 파악하고 나면 그 때서야 어디를 어떻게 시작해야 할지 목표를 설정할 수가 있는 것입니다. 흐름을 파악해야 하는 주요 목적은 어디를 어떻게 봐야 하는지 목표를 설정하는 것과 일맥 상통한다고 볼 수 있습니다. 이리 되면 필요한 부분에 Log 를 심는다던지 디버거를 이용한 다던지 하면서 데이터가 어떻게 흐르는지 파악을 하고 자세하게 필요한 부분을 살펴볼 수가 있습니다. 즉 정리하자면 

 

1. 프로그램이 어떻게 구동되는지 흐름을 파악한다. 
2. 세부 프로세스가 어떤식으로 함수가 호출되는지 파악한다. 
3. 함수에서 사용되는 데이타가 어떤식으로 흘러가는지 파악한다. 
4. 그 데이타가 어떤 구조체 (structure, class)에 담겨있는지 파악한다. 


  이런식으로 굵직하게 흐름을 파악하는 식으로 나아가면 단기간에 빠르게 소스를 분석할 수가 있습니다. 어느 정도에 이르신 분들에게는 필요 없는 팁일 수가 있지만, 이제 막 프로그램의 재미를 익혀나가서 다른 고수들의 프로그램을 살펴볼 필요가 있는 분들에게는 도움이 될 것입니다. 

ps. 
 
요즘 블로그에 소홀한 이유는 변명 아닌 변명이겠지만 지금 하고 있는 일이 바쁘고 난이도가 높기 때문입니다. 간만에 청춘으로 돌아간 듯 밤 늦게 까지 모니터를 쳐다보며 지내는 시간이 많아서 입니다. (물론 그렇다고 놀지 않는다는 말은 아니지요 ㅎㅎ)  
작은 노트북을 가지고 다닐 때 소스 코딩 작업을 할 때, 큰 모니터 만큼 편한게 없습니다. 들고 다니기 편하기 때문에 주로 13인치 작은 맥북을 들고 다니기 때문에 회사에서 작업시 항상 큰 모니터를 연결해서 씁니다. 보통 24인치 모니터를 지급 받아서 붙이기 때문에 1080P 정도로도 충분했습니다. 그러나 이번에 지급 받은 것은 27인치를 지급 받았기 때문에 1440P 로 써야 했습니다. 그런데 문제는 일반적으로 맥북프로에서 1440P 를 지원하게 할려면 보통 알려진 방법 (DVI 변환 단자) 으로는 안됩니다. 

그냥 결론부터 말하면 맥북프로에서 듀얼모니터로 1440P 를 지원하게 할려면 두가지 방법 밖에 없습니다.  

1. '듀얼링크 DVI 커넥터 - MDP' 로 연결하는 방법입니다. 

 맥북프로에서 쓰이는 듀얼링크 DVI 커넥터 링크 

 가격이 무려 16만원 가까이 됩니다. 뭐 이렇게 비싼건 이유가 있어서라고 합니다. 애플이라서 듀얼링크 DVI 신호를 변환하는것이 쉬운게 아닌가 봅니다. 그나마 이것보다 가격을 적게 들어서 해결할려면 

2. 모니터가 DisplayPort 를 지원하면 됩니다. 

 모니터가 DisplayPort 를 지원하면 맥북에 있는 Mini DisplayPort 와 연결하는 방법이 있습니다. 커넥터는 만원인가 이만원이였던 것 같습니다. (맥북에 있는 미니 디스플레이포트는 일반 디스플레이 포트를 접속 방식만 바꾼것이라고 합니다. 쯧 애플이란.. ) 

굳이 이렇게 글을 남기는 것은 저처럼 고생하시지 마시고 (뭐를 알아보셔도 안된다는 것을 확인하실 것입니다..) 그냥 2 번으로 생각하시고 모니터 사실 때 고민하시라는 이야기 입니다. (저는 환불하고 야단도 아니였습니다.) 


Android NDK (Native Development Kit) 을 이용해서 개발하고 있습니다. NativeActivity 를 이용하고 있습니다. 그런데 작지만 해결하기 어려운 버그가 있습니다. 

NativeActivity 는 Java 의 Activity 의 일종인데 JNI 를 이용한 Native C/C++ Entry Point 를 쓰레드 (Thread)를 이용해서 호출하는 부분을 잘 감싸서 NDK 를 이용해서 개발하고자 하는 사람들에게 편의를 제공할려는 목적으로 만들어 진것으로 보입니다. 특히나 게임 , 전화, 멀티미디어 용 어플리케이션을 개발하는 사람들은 필히 관심을 가져볼 만합니다. 

발생한 이슈는  제가 추천한 책에서 언급된 소스에 다른 모듈을 붙일려고 하는 순간에 발생했습니다. 참고로 만들어본 Android.mk 파일입니다. 



LOCAL_PATH := $(call my-dir)
TOP_ROOT_PATH := $(LOCAL_PATH)

include $(call all-subdir-makefiles) 
# 이 하위 Android.mk 에서 Shared Library 를 만들어 줍니다. 
# 그 라이브러리 이름을  codec 이라고 (예를 들어서) 해줍니다. 

include $(CLEAR_VARS)

LOCAL_PATH = $(TOP_ROOT_PATH)

LS_CPPP=$(subst $(1)/, ,$(wildcard $(1)/*.cpp ))

LOCAL_MODULE := game 
LOCAL_SRC_FILES := $(call LS_CPPP,$(LOCAL_PATH))

LOCAL_CFLAGS += -D GL_GLEXT_PROTOTYPES

LOCAL_LDLIBS := -landroid -llog -lEGL -lGLESv1_CM
LOCAL_STATIC_LIBRARIES := android_native_app_glue png
LOCAL_SHARED_LIBRARIES := codec                          
# 이 부분이 문제의 그 부분입니다. 

include $(BUILD_SHARED_LIBRARY)

$(call import-module, android/native_app_glue)
$(call import-module, libpng)


이게 대체 뭐지? 라고 생각하시는 분들은 제가 곧 'NDK 프로그래밍 따라하기' 포스트 한 두개를 올릴테니 그 때까지 이 부분을 보실 필요는 없습니다. 

위의 Android.mk 를 이용해서 컴파일을 하면 libgame.so 가 만들어 집니다. 책에서 나와 있는 그대로 만들어 집니다. 그러나 codec 이라는 (libcodec.so)를 이용해야 하는 필요가 생겨서 따로 만들어 줘서 프로젝트에 포함시켜 주면 실행이 안되고 에러가 발생합니다. 

잘 된 캡슐화의 문제점 중의 한가지가 난감한 에러가 발생하면 해결하기 어렵다는 점입니다. 구글링도 해보고 여러가지 독립적인 테스트를 해 본 결과 전혀 엉뚱한 작업을 진행중에 해결이 됐습니다. 100% 확신을 한 바는 아니지만 NativeActivity 가 결국 Java 클래스 이고 내부적으로는 결국 JNI 를 이용해서 Library 를 불러오는데, 정해진 방법으로만 호출하기 때문에 (위의 예제의 경우에는 libgame.so ) 다른 라이브러리를 호출을 못하기 때문에 발생하는 것 같습니다. 따라서 해결해 주기 위해서는 몇가지 수동으로 처리해 줘야 합니다. 

$ cd $PROJECT_ROOT
$ cd src/com/comjuck/game     (없으면 만들어 주셔야 합니다)
$ emacs NativeActivity

package com.comjuck.game;

import android.app.NativeActivity;
import android.os.Bundle;

public class GameActivity extends NativeActivity {

	static {
		System.loadLibrary("codec");
	}


  @Override
  protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    
  }
  
}


GameActivity 를 만들어주고 NativeActivity 에서 상속을 받습니다. (물론 package 경로에 맞춰주는 것을 잊어주시면 안됩니다) , 그리고 위에서 표기한 대로 추가해 준 라이브러리를 직접 불러줍니다. 
그리고 AndroidManifest.xml 을 열어서 추가해 준 Activity 를 android.app.NativeActivity 대신 지정해 줍니다. 

$ cd $PROJECT_ROOT
$ emacs AndroidManifest.xml 
 

    <activity android:name="PhoneActivity"
                  android:label="@string/app_name">


이제는 문제 없이 앱이 실행되는군요. 

ps. 이걸 알아내기 위해서 4시간을 소모했습니다. ㅜ.ㅜ 

저는 Command Line 에서 GIT 을 쓰고 있습니다. '뭐든지 가장 기본이 되는 것부터 마스터를 하자!' 라고 평소 떠들고 다니기도 하지만, CLI (Command Line Interface) 가 가장 마음이 편안해 (?) 지는 환경이기 때문이도 합니다. 그러나 Eclipse 에서 개발이 최적화 되어 있는 분들은 어떤 방식이 되도 무조건 Eclipse 에서 돌아가길 원합니다. (진정한 IDE 라고 할 수 있죠) 그런분들에게 추천하고 싶은 포스트가 있습니다. 

http://www.vogella.com/articles/EGit/

일단 포스트 주소입니다. 그리고 이 포스트와는 별도로 저 분의 사이트는 안드로이드 개발하는 분들에게 참조가 될 만한 내용을 정말 많이 가지고 있어서 즐겨찾기 해두시고 가끔가다 찾으시면 효율이 좋을 것입니다. 

 



스티브 잡스가 요즘 일반적으로 사용되는 이메일을 업무적으로 사용해서 팀의 지리적인 거리를 없애고 어떻게 의사 결정자가 CC 만으로 프로젝트에 참여할 수 있는 것인지.. 

멀티미디어가 앞으로 '수단'이 되는 것이 당연하며, 절대 목적이 아니며 , 목적은 사람들 간의 커뮤니케이션이 될 것이라고 예언하는 동영상입니다.

다만 제가 이 것을 페북에 올릴 때 '스티브 잡스의 예언' 이라고 안 올리고 '어느 젊은 사업가의 예언' 이라고 올리니 반응이 전혀 없더군요. (물론 젊을 때 모습이라 스티브 잡스의 이미지와 매치가 안되는 경우를 고려했지만..)

그래서 이름이 알려지는 게 얼마만큼 중요한지 새삼 깨닫게 된 작은 실험이였습니다. (속된말로 좋은 프레젠테이션을 하고 싶다면, 유명한 사람을 데려오면 된다.. 라는 진리를 깨달았다고나 할까요? ㅎㅎ)

 
저는 안드로이드를 Emacs 로 개발하고 있는 중인데요. 외부 jar 가 추가 될 때 자동으로 classpath 에 추가 하고 자동으로 import 기능을 활성화 시키는 방안을 찾는 중인데, 없더군요.. 

물론 Eclipse 를 사용하면서 Google AdMob SDK 같은 외부 jar를 사용하기는 쉽습니다. 외부 라이브러리로 추가해 주면 끝이기 때문입니다. 다만 CLI (Command Line Interface) 에서 Ant 를 이용해서 빌드를 할 때는 마구 마구 귀찮아집니다. 하지만 쉽게 하는 방법이 생겼더군요. 

$(ANDROID_PROJECT_ROOT) 밑에 /libs 라는 디렉토리를 만들고 그 안에다가 GoogleAdMobAdsSdk-6.0.1.jar android-support-v4.jar 두개의 파일을 복사해줍니다. 


$(ANDROID_PROJECT_ROOT) 밑의 ant.properties 파일을 열고 다음과 같이 추가해 줍니다. 

  jar.libs.dir=libs


이제 

$ ant clean && ant debug 



해 주시면 성공적으로 바인딩 되는 것을 확인하실 수 있습니다. 

다만 위와 같이 따로 libs 를 추가해 주면 JDE 환경에서 자동으로 classpath 뒤져서 Import 해주는 기능이 libs 에 추가된 jar 에 대해서는 동작하지 않습니다. 이럴 때를 위해서 따로 함수를 만들어 뒀습니다. (100% 제가 만든것입니다 쿨럭..) 



(defun android-mode-my-hook () 
  (progn
    (and (file-exists-p 
          (concat (android-root) "/libs"))
         (setq jde-global-classpath 
               (append jde-global-classpath 
                       (directory-files
                        (concat (android-root) "/libs")
                        t "jar"))))
    ))
(add-hook 'android-mode-hook 'android-mode-my-hook)


다음과 같이 만들어 주면 됩니다. 저는 java 설정만 따로 모아놓고 쓰지만 그렇지 않으신 분들은 .emacs 파일 구석에 적어두시면 될 것입니다. 물론 jdee 와 android-mode 설정 뒤에 적어주셔야 할 것입니다. jde-global-classpath 는 jdee 를 추가 해줘야 생기는 변수고 android-root 는 안드로이드 프로젝트의 루트를 찾아주는 편리한 함수인데 android-mode 를 추가해줘야만 쓸 수가 있습니다. 

점점 lisp 으로 코딩하는게 재밌어 지기 시작합니다. ㅎㅎ 
 
요즘 Android NDK 를 이용해서 개발을 진행중인데, 화가 나는(?) 일이 발생해서 포스팅을 남기게 되었습니다. $(NDK_HOME)/docs/PREBUILTS.html 에 보면 

A prebuilt module does not build anything. However, a copy of your prebuilt shared library will be copied into $PROJECT/obj/local, and another will be copied and stripped into $PROJECT/libs/<abi>.

 
이런 문구가 있습니다. 하지만 시키는 대로 하니 복사는 커녕 어떠한 동작도 발생하지 않는 것을 발견했습니다. 미치는 지 알았습니다. 한 두시간을 구글링 했어도 어디에서도 명확히 답을 주는 부분이 없었습니다. 보통 이정도라면 방법은 하나 입니다. 직접 빌드 시스템을 까보는 수밖에 없지요.  

$(NDK_HOME)/build/core/prebuilt-static-library.mk 

위의 파일이 prebuilt-static-library 에 관한 부분입니다. 그 안을 보면 다음과 같은 문구가 있습니다. 

# Prebuilt static libraries don't need to be copied to TARGET_OUT
# to facilitate debugging, so use the prebuilt version directly
# at link time.


즉 요약을 하자면, 매뉴얼에서는 복사를 한다고 써 있지만, 실제로 동작하는 코어 모듈에서는 직접 링크를 하라는 식으로 쓰여져 있더군요. 

결론은 prebuilt-static-library 를 사용할려면 실제로 매뉴얼에 있는대로 동작을 하지 않습니다. 직접 라이브러리 링크를 걸어주시기를 추천합니다. 
 

+ Recent posts