기본 콘텐츠로 건너뛰기

안드로이드 native c++ 컴파일 관련 정리 


# 툴체인 선택

표 1. 다양한 명령 집합에 대한 APP\_ABI 설정

| 아키텍처 | 툴체인 이름 |
| ---------- | ------------------------------------ |
| ARM 기반 | arm-linux-androideabi-**{gcc-version}** |
| x86 기반 | x86-**{gcc-version}** |
| MIPS 기반 | mipsel-linux-android-**{gcc-version}** |
| ARM64 기반 | aarch64-linux-android-**{gcc-version}** |
| X86-64 기반 | x86\_64-**{gcc-version}** |
| MIPS64 기반 | mips64el-linux-android-**{gcc-version}** |

# Sysroot 선택

```
SYSROOT=$NDK/platforms/android-21/arch-arm 
```

# 컴파일러 호출

## 간단한 호출

다음은 NDK 내에 미리 빌드 되어있는 `arm-linux-androideabi-4.8` 툴체인을 이용한 빌드 방법이다.

```
export CC="$NDK/toolchains/arm-linux-androideabi-4.8/prebuilt/ \
  linux-x86/bin/arm-linux-androideabi-gcc-4.8 --sysroot=$SYSROOT" $CC -o foo.o -c foo.c 
```

이 방법에서는 C++ STL (STLport, libc++ 또는 GNU libstdc++)을 사용할 수 없습니다. 예외나 RTTI가 지원되지도 않는다.

## 고급 방법

NDK는 명령줄에서 사용자 지정 툴체인 설치를 수행할 수 있는 `make-standalone-toolchain.sh` 셸 스크립트를 제공합니다.

`$NDK/build/tools/` 디렉터리에 있으며, 여기서 $NDK는 NDK의 설치 루트 디렉터리입니다.

```
$NDK/build/tools/make-standalone-toolchain.sh \
  --arch=arm --platform=android-21 --install-dir=/tmp/my-android-toolchain 
```

이 명령어를 실행하면 `/tmp/my-android-toolchain/`이라는 이름의 디렉터리가 생성되고, 이 디렉터리에는 `android-21/arch-arm` sysroot의 복사본과 32비트 ARM 아키텍처용 툴체인 바이너리의 복사본이 포함됩니다.

표 3. `--arch`를 사용하는 툴체인과 해당 값

| 툴체인 | 값 |
| ----------------- | ----------------- |
| mips64 컴파일러 | \--arch=mips64 |
| mips GCC 4.8 컴파일러 | \--arch=mips |
| x86 GCC 4.8 컴파일러 | \--arch=x86 |
| x86\_64 GCC 4.8 컴파일러 | \--arch=x86\_64 |
| mips GCC 4.8 컴파일러 | \--arch=mips |

표 4. `--toolchain`을 사용하는 툴체인과 해당 값

| 툴체인 | 값 |
|:-------------:|:-------------------------------------------------------------------------:|
| arm | --toolchain=arm-linux-androideabi-4.8 
--toolchain=arm-linux-androideabi-4.9
--toolchain=arm-linux-android-clang3.5
--toolchain=arm-linux-android-clang3.6|
| x86 | \--toolchain=x86-linux-android-4.8   
\--toolchain=x86-linux-android-4.9   
\--toolchain=x86-linux-android-clang3.5   
\--toolchain=x86-linux-android-clang3.6 |
| mips | \--toolchain=mips-linux-android-4.8   
\--toolchain=mips-linux-android-4.9   
\--toolchain=mips-linux-android-clang3.5   
\--toolchain=mips-linux-android-clang3.6 |
| arm64 | \--toolchain=aarch64-linux-android-4.9   
\--toolchain=aarch64-linux-android-clang3.5   
\--toolchain=aarch64-linux-android-clang3.6 |
| x86\_64 | \--toolchain=x86\_64-linux-android-4.9   
\--toolchain=x86\_64-linux-android-clang3.5   
\--toolchain=x86\_64-linux-android-clang3.6 |
| mips64 | \--toolchain=mips64el-linux-android-4.9   
\--toolchain=mips64el-linux-android-clang3.5   
\--toolchain=mips64el-linux-android-clang3.6 |

# CMakeList.txt

```
# For more information about using CMake with Android Studio, read the 
# documentation: https://d.android.com/studio/projects/add-native-code.html  
# Sets the minimum version of CMake required to build the native library.  
cmake_minimum_required(VERSION 3.4.1)  

# Creates and names a library, sets it as either STATIC 
# or SHARED, and provides the relative paths to its source code. 
# You can define multiple libraries, and CMake builds them for you. 
# Gradle automatically packages shared libraries with your APK. 
```

다음은 .cpp 라이브러리 추가하는 방법이다.

```
add_library( # Sets the name of the library.
             native-lib
             
             # Sets the library as a shared library.
             SHARED
             
             # Provides a relative path to your source file(s).
             src/main/cpp/native-lib.cpp
           ) 
```

```
add_library( # Sets the name of the library.
             blerp
             
             # Sets the library as a shared library.
             SHARED
             
             # Provides a relative path to your source file(s).
             src/main/cpp/detection/blerp.cpp
           )
           
add_library( # Sets the name of the library.
             util
             
             # Sets the library as a shared library.
             SHARED
             
             # Provides a relative path to your source file(s).
             src/main/cpp/detection/util.cpp
           )
           
add_library( # Sets the name of the library.
             input-processing
             
             # Sets the library as a shared library.
             SHARED
             
             # Provides a relative path to your source file(s).
             src/main/cpp/detection/input_processing.cpp
           ) 
```


add_library 의 세번째 파라미터에 여러 cpp 파일을 묶어 하나의 라이브러리로 등록할 수 있다. (좋은 의견을 주신 코드몬님 감사드립니다. )

```
add_library( # Sets the name of the library.
             native-lib2

             # Sets the library as a shared library.
             SHARED

             # Provides a relative path to your source file(s).
             native-lib.cpp common/hmac.cpp common/sha1.cpp common/sha256.cpp
            )
```

다음은 헤더 파일을 포함하고 있는 디렉토리를 선언하는 코드이다.

```
# Specifies a path to native header files. include_directories( src/main/cpp/include ) 
```

다음은 라이브러리를 찾아서 해당 라이브러리에 이름을 할당하는 코드이다.

```
# Searches for a specified prebuilt library and stores the path as a 
# variable. Because CMake includes system libraries in the search path by 
# default, you only need to specify the name of the public NDK library 
# you want to add. CMake verifies that the library exists before 
# completing its build.  

find_library( # Sets the name of the path variable.               
              log-lib
              
              # Specifies the name of the NDK library that
              # you want CMake to locate.
              log 
            ) 
```

다음은 라이브러리의 target을 정의하는 코드이다.

```
# Specifies libraries CMake should link to your target library. You 
# can link multiple libraries, such as libraries you define in this 
# build script, prebuilt third-party libraries, or system libraries.   
target_link_libraries( # Specifies the target library.                        
                       native-lib
                       
                       # Links the target library to the log library
                       # included in the NDK.
                       ${log-lib} 
                     ) 
```

input_processing 은 util에 종속되어 있고, util은 blerp에 종속되어있다.

```
target_link_libraries( input-processing util ) 
target_link_libraries( util blerp ) 
```

# 여담

C와 C++이 섞여 있는 코드를 이용할 때, C에서 만들어진 함수의 이름과 C++에서 선언한 함수의 이름을 비슷한 형식으로 만들어서 C++에서 컴파일된 함수를 C에서도 사용할 수 있도록 한다.

-   [C++ 상에서 발생하는 name mangling 에 관한 내용](https://spikez.tistory.com/19)

extern "C"를 명시적으로 선언해 줌으로써 이 부분에 선언된 함수는 C 형식의 함수 실행 이름을 가지게 되고, 이를 C에서도 사용할 수 있게 된다. 이 때 함수의 선언 형식은 C의 기준을 따라야 하며, C++의 기준(클래스를 명시한다던지, template을 이용하는 등)을 따르는 함수는 오류를 발생한다.

-   [What is the effect of extern “C” in C++?](https://stackoverflow.com/questions/1041866/what-is-the-effect-of-extern-c-in-c)

```
// blerp.h 
#include 
typedef struct {
    uint32_t *pixels;
    unsigned int w;
    unsigned int h;
} image_t; 

#define getByte(value, n) (value >> (n*8) & 0xFF)

#ifdef 
__cplusplus extern "C" { 
#endif  

void copy_element(image_t *image, unsigned int x, unsigned int y, uint32_t color);  

#ifdef 
__cplusplus } 
#endif 
```

# 참고

- [C 및 C++ 코드를 프로젝트에 추가](https://developer.android.com/studio/projects/add-native-code?hl=ko)
- [독립 실행형 툴체인](https://developer.android.com/ndk/guides/standalone_toolchain?hl=ko)
- [CMake: target\_link\_libraries](https://cmake.org/cmake/help/v3.12/command/target_link_libraries.html)
라벨:

댓글

댓글 쓰기

이 블로그의 인기 게시물

NGINX module 개발 시 참고 하기 좋은 글

## 🙋 NGINX 모듈은 언제 만드나요? Nginx 는 많은 웹 서비스들에서 사용하는 웹 서버 프로그램 입니다. Nginx 는 그 자체로 강력하고, 다양한 모듈을 가지고 있기 때문에 많은 서비스들에서 사용됩니다. 하지만 서비스의 요구사항에 따라서, Nginx 그 자체만으로는 부족한 상황이 발생합니다. 앱 서버에서 처리하기에는 앱의 로직과는 동떨어져있어 책임원칙에 위반하고, nginx 의 설정 로직에서 처리되면 좋을 것 같은 요구사항들이 있습니다. 예를 들면, 프록시를 할 때 특정 값을 가공하여 넘겨주고 싶을 수 있습니다. 또, header 에 있는 값을 가지고 `$remote_addr` 를 변조하여 사용하고 싶다거나 하는 상황이 있습니다. 그런 상황에서 적절한 처리를 할 수 있는 nginx 모듈을 직접 만들어 nginx 에 적용해줄 수 있습니다. Nginx 는 C 언어로 만들어져 있어 모듈도 보통 C 로 작성됩니다. 하지만 최근에는 [Lua](https://github.com/openresty/lua-nginx-module#readme) 로 작성하거나 [njs (nginx 에서 사용하기 위한 일종의 custom js)](https://nginx.org/en/docs/njs/) 를 사용하여 모듈이 작성되기도 합니다. 하지만 이 글에서는 C 언어로 Nginx 모듈을 작성할 때 참고하기 좋은 글들을 소개합니다. ## Nginx 공식 문서 > https://nginx.org/en/docs/dev/development_guide.html 공식 문서는 어떤 상황에서든지 중요한 것 같습니다. 이미 만들어진 프로그램에 대해서 추가로 개발할 때는 설명서를 자세하게 살펴봐야 합니다. 공식 문서에서는 Nginx 에서 사용되는 자료형과 구조체, 변수, 로그 방식부터 Nginx 가 HTTP 관련 요청을 처리하는 방식 등 다양한 내용들이 기록되어 있습니다. 따라서 모듈을 개발하는 경우가 아니더라도, Nginx 를 깊게 이해하고 싶다면 한번 쯤 읽...
댓글 쓰기
자세한 내용 보기

서버에서 Client IP 를 추출하는 여러가지 방법

서비스 요구사항에 따라 Client IP 가 필요한 상황이 있다. 보안을 위해서 Client IP 를 확인하여 접근을 허용할 수 있다. 허용되지 않은 IP 의 경우 접근을 막을 수 있다. 로그 요구사항으로 어떤 사용자가 접근하고 있는 지를 기록하기 위해 Client IP 를 남겨야 할 수 있다. 하지만 사용자나 서비스의 네트워크 구성에 따라서 Client IP 를 추출하는 것이 쉽지 않을 수 있다. 프록시가 있어 직접 연결한 Client 를 실제 사용자로 판단할 수 없는 경우가 그렇다. 프록시 뒤에 있는 사용자를 찾으려고 노력하면 Client IP 를 숨기거나 우회하기 위해서 변조를 시도하는 상황을 마주하게 된다. 그래서 Client IP 를 추출하기 위한 여러 방안들을 아래에 정리하게 되었다. 결론부터 먼저 말하면, 일반적인 상황에서 나는 `X-Forwarded-For` 의 가장 오른쪽의 Public IP 를 Client IP 로 판단하기로 했다. 믿을 수 없는 목록 중에서 신뢰할 수 있으면서 간단하고, 빠른 방법이라 생각하기 때문이다. 하지만 여러 방안들을 조사했을 때, 어떤 상황에서는 사용할 수 있는 지, 또 어떤 지점이 문제가 되는 지 생각해볼 수 있었다. 그래서 고민했었던 여러 방안들을 소개하려고 한다. ### Remote IP 프록시가 없는 간단한 구조의 서비스라면 서버에 연결된 Remote IP 를 Client IP 로 추출할 수 있다. 하지만 Remote IP 가 실제 사용자의 IP 라는 확신이 없다면, Client IP 로 사용하기 어렵다. 사용자 네트워크 구성에서 proxy 가 있다면, 서버에 연결된 Remote IP 는 실제 사용자의 Client IP 가 아닐 수 있다. 여기에서 서비스 요구사항에 대한 명확한 정의가 필요해질 수 있다. 사용자 네트워크의 사설 IP 를 추출해야 하는 지, 아니면 공인 IP 를 추출해야 하는 지 정의가 필요하다. 사설 IP 는 서비스의 입장에서 큰 의미가 없기 때문에, 보통 공인 IP...
댓글 쓰기
자세한 내용 보기