[한화비전 VEDA 4기] 8주차 리뷰

8주차 부터는 mobaXterm을 통해 작업을 하게 되었습니다.
사실 이 툴이 뭔지 중요하지는 않습니다. 그냥 터미널 중 하나라고 생각하면 될 듯 합니다. 현업에서 많이 사용한다고는 하네요. 확실히 파일 옮기는 것은 매우 편했습니다. 저는 원래 scp나 sftp같은걸로 이동시켰으니까 드래그 앤 드롭으로 이동시키는건 진짜 확실해 좋았습니다ㅋㅋ

리눅스 개발 도구

리눅스 개발은 GCC, GDB 등의 도구들을 이용합니다.
gcc는 C언어 컴파일러입니다. gdb는 디버깅 도구이구요. 리눅스에서 가장 많이 사용하는 디버깅 툴 중 하나라고 합니다.

GCC 최적화

컴파일러들은 우리가 만든 코드를 최적화시키는 작업을 진행합니다. 아무 일도 수행하지 않는 코드를 지우거나 하는 등의 일을 하는거죠. 이런 컴파일러 최적화는 총 4단계가 존재하며 -O0부터 -O3까지 옵션을 넣어서 만들어줍니다.
그 중 -O3은 코드의 변형 우려가 있기 때문에 사용을 추천하지 않는다고 합니다.

GDB

다음으로 gdb에 대해 간략하게 살펴보도록 합시다. 디버깅은 매우 중요합니다. 어떠한 버그가 존재할 때, 어디서 어떻게 문제가 생겼는지 알지 못한다면 코드를 작성하기 어려울 것입니다. gdb는 디버깅을 하며 코드를 한 줄 한 줄 확인하며 주소값까지 확인할 수 있는 아주 유용한 툴입니다. 다만 -g 옵션을 넣어 컴파일을 해 주어야 디버깅이 가능하며, 이렇기 때문에 printf()와 같은 이미 만들어진 라이브러리 함수들은 디버깅 대상이 아닙니다. 배포용에서는 해당 옵션을 빼기 때문입니다.

원격 디버깅을 하기 위해서는 gdbserver를 디버깅을 하려는 장치에 설치해준 뒤, 개발 장비에서 gdb-multiarch를 이용하면 가능합니다.

# 디버그 서버 여는 법
sudo apt install gdbserver

gdbserver <아이피(생략가능)>:<포트번호> <파일 이름>

# 개발 장비에서 사용법
gdb-multiarch <파일 이름>

(gdb) target remote <Ip addr>:<포트번호>

라이브러리

코딩을 하다보면 라이브러리라는 말을 많이 듣곤 합니다. 라이브러리는 미리 짜 둔 코드를 링크하여 갖다 쓰는 것들을 이야기합니다.
라이브러리는 3종류로 나뉘어집니다. 정적 라이브러리, 공유 라이브러리, 그리고 동적 라이브러리 입니다.

정적 라이브러리

정적 라이브러리는 링크 단계에서 코드를 모두 붙이는 라이브러리입니다. .a 확장자를 가지고 있습니다.
라이브러리를 만드는 방법은 다음과 같습니다.

# 우선, object 파일을 생성합니다.
gcc -c add.c sub.c mul.c div.c

# ar 명령어를 통해 정적 라이브러리 파일을 생성합니다.
# 이 때, libcalc.a 처럼 lib[파일이름].a 의 형식이 일반적으로 사용됩니다.
ar -rv libcalc.a add.o sub.o mul.o div.o

# 컴파일 시, -L은 라이브러리 위치, -l은 라이브러리 이름을 적어주면 된다. 접두어인 lib와 확장자인 .a는 적지 않습니다.
gcc main.c -o main -L. -lcalc

이렇게 만들면 libcalc.a 라는 정적 라이브러리가 생성됩니다.

정적 라이브러리의 경우, 여러 코드에서 사용할 때 동일할 라이브러리를 매 번 메모리에 올려야 한다는 단점이 존재합니다. 이를 보완하기 위해 공유 라이브러리와 동적 라이브러리가 탄생하였습니다.

공유 라이브러리

공유 라이브러리의 경우, .so 확장자를 가집니다.
정적 라이브러리와는 달리, 실행 파일에는 라이브러리의 정보만 넣어줍니다. 라이브러리 코드는 한 번만 메모리에 올라가서 많은 프로그램이 이용하여도 공간을 적게 잡아먹는다는 장점이 존재합니다.

공유 라이브러리를 만드는 방법은 다음과 같습니다.

# 공유 라이브러리를 컴파일해줍니다. 여기에 -fPIC 라는 옵션을 넣어서 컴파일해야 합니다.
gcc -fPIC -c add.c
gcc -fPIC -c sub.c
gcc -fPIC -c mul.c
gcc -fPIC -c div.c

# 공유라이브러리 파일을 만들어줍니다. -shared 옵션을 통해 공유라이브러리임을 명시합니다.
# 접두어로 lib를 붙이고 확장자는 .so로 합니다.
ld -shared -o libcalc.so add.o sub.o mul.o div.o

# 공유라이브러리를 명시해준 뒤, 프로그램을 컴파일해줍니다. 역시 -L은 라이브러리 위치, -l은 공유라이브러리의 이름입니다. 이 때 lib와 확장자는 뺍니다.
gcc -o calc calc.o -L. –lcalc

# 만약 공유라이브러리의 위치를 찾을 수 없다면 다음을 실행해야 합니다. 공유라이브러리의 위치를 현재 위치로 잡아주는 명령어입니다.
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.

공유 라이브러리는 정적 라이브러리에 비해 공간을 덜 잡는다는 장점이 있지만, 반드시 라이브러리가 메모리 위에 존재해야 한다는 단점이 존재합니다. 누가 라이브러리를 사용하지 않더라도 메모리 위에 있어야 할 수도 있습니다.

동적 라이브러리

동적 라이브러리는 이러한 공유 라이브러리의 문제점을 해결하기 위해 등장하였습니다. 정적 라이브러리와 달리 프로그램이 실행 중에 라이브러리를 불러오는 거죠.
다만 이렇게 하면 공유는 불가능하다고 합니다.
동적 라이브러리는 dlfcn.h 라는 특수한 헤더 파일을 미리 로드해야 사용이 가능합니다.

makefile, cmake

내용이 너무 길어지기 때문에 간략히 적고, 나중에 따로 정리하도록 하겠습니다.
makefile과 cmake는 모두 C/C++ 코드가 복잡해짐에 따라 빌드하기 어려운 것을 간단히 만들어주기 위해서 등장하였습니다.
빌드 시스템의 자동화라고 생각하면 될 듯 합니다.

OBJS = main.o a.o b.o

main: $(OBJS)
    $(CC) -o $@ $(OBJS)

%.o: %.c

clean:
    rm main $(OBJS)

간단한 makefile의 예시입니다. 이런식으로 파일을 만든 뒤, make 명령어를 통해 실행 가능합니다.
cmake역시 마찬가지입니다. cmakelist.txt에 명세를 한 뒤, cmake --build 를 통해 빌드할 수 있습니다.
cmake의 경우, 일반적으로 build 파일을 만들어 빌드를 진행하는데, 이렇게 되면 나중에 빌드를 다시할 때 build 파일만 삭제해도 된다는 장점이 존재합니다.