Golang - GLIBC 의존을 없애는 정적 빌드 방법
닷넷 AOT 빌드에서 GLIBC 버전 문제를 겪었더니,
C# - 리눅스용 AOT 빌드를 docker에서 수행
; https://www.sysnet.pe.kr/2/0/13487#glibc
Go 언어로 빌드한 바이너리에 대해서도 확인이 필요하겠다 싶었습니다. 우선, Ubuntu 22.04에서 빌드한 경우,
$ go build -o /mnt/c/temp/testapp testapp
$ file /mnt/c/temp/testapp
/mnt/c/temp/testapp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go BuildID=kjE...[생략]...3Doy, with debug_info, not stripped
$ objdump -p /mnt/c/temp/testapp
...[생략]...
Version References:
required from libc.so.6:
0x069691b4 0x00 02 GLIBC_2.34
0x069691b2 0x00 03 GLIBC_2.32
0x09691972 0x00 04 GLIBC_2.3.2
0x09691974 0x00 05 GLIBC_2.3.4
0x09691a75 0x00 06 GLIBC_2.2.5
기본적으로는 저렇게 glibc에 의존적인 바이너리를 생성합니다. 당연히 저 실행 모듈을 20.04, 18.04에서 실행하면 버전 오류가 발생합니다.
// 22.04에서 빌드한 바이너리를 20.04에서 실행
$ /mnt/c/temp/testapp
/mnt/c/temp/testapp: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /mnt/c/temp/testapp)
/mnt/c/temp/testapp: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /mnt/c/temp/testapp)
재미있는 점은, 저 빌드를 Ubuntu 20.04에서 하면 glibc의 버전이 확 낮춰진다는 점입니다.
// Ubuntu 20.04에서 빌드한 경우
$ objdump -p /mnt/c/temp/testapp
...[생략]...
Version References:
required from libpthread.so.0:
0x09691972 0x00 02 GLIBC_2.3.2
0x09691a75 0x00 03 GLIBC_2.2.5
required from libc.so.6:
0x09691974 0x00 04 GLIBC_2.3.4
0x09691a75 0x00 05 GLIBC_2.2.5
가장 높은 버전이 2.3.4니까...
웬만한 리눅스 환경에서 전부 실행된다고 보면 됩니다.
그런데, 저 빌드를 Windows 환경에서 GOARCH, GOOS 환경변수와 함께 cross-compile로 빌드하면,
C:\temp\testapp> set GOARCH=amd64
C:\temp\testapp> set GOOS=linux
C:\temp\testapp> go build -o c:\temp\testapp testapp
해당 결과물은 Ubuntu 18.04에서조차 실행이 잘됩니다. 왜냐하면,
$ ldd /mnt/c/temp/testapp
not a dynamic executable
$ file /mnt/c/temp/testapp
/mnt/c/temp/testapp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, with debug_info, not stripped
glibc에 대해 정적 링킹이 됐기 때문입니다. 아마도 Windows 환경에서 빌드하는 경우, 현재 시스템에 glibc가 아예 존재조차 하지 않으니 어쩔 수 없이 정적 링킹을 할 수밖에 없었을 것입니다.
리눅스 환경에서 빌드하는 경우에도 정적 링킹을 명시적으로 하고 싶다면, CGO_ENABLED=0 환경변수를 설정하면 됩니다.
$ CGO_ENABLED=0 go build -o /mnt/c/temp/testapp testapp
$ file /mnt/c/temp/testapp
/mnt/c/temp/testapp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=w...[생략]...Hc6, with debug_info, not stripped
참고로 dockerfile을 경유해 빌드하고 싶다면,
FROM golang:1.21.4
WORKDIR /app
이미지를 만들고,
c:\temp> docker build -t go-build-machine -f build.dockerfile .
다음과 같이 명령을 수행하면
docker run -e CGO_ENABLED=0 -v /c/temp/testapp:/app -v /c/temp:/output --name go-build-machine-instance --rm -it go-build-machine /bin/bash -c "go build -o /output/testapp testapp"
c:\temp 디렉터리에 testapp 바이너리가 생성됩니다.
"golang:1.21.4" 이미지의 기반 버전이 bookworm이므로 Ubuntu로는 22.04 또는 22.10 버전에 해당합니다. 만약 CGO_ENABLED=0 옵션 없이 빌드했다면 2.34 의존성을 갖게 됩니다.
마치기 전에, go build의 ldflags에 준 옵션을 보면,
$ go build -ldflags="-help"
...[생략]...
-s disable symbol table
...[생략]...
-w disable DWARF generation
...[생략]...
"-w" 옵션은 DWARF 정보 생성을, "-s" 옵션은 디버깅 심벌 테이블 정보를 제어합니다. 실제로 테스트를 해보면, 크기에서 약간 차이가 나고,
[기본 옵션] 4,781 KB
[-s 적용] 3,136 KB
[-w 적용] 3,393 KB
[-s, -w 2개 적용] 3,136 KB
-s를 적용 시와 2개 모두 적용했을 때의 크기가 같은 것을 보면 symbol table이 없다면 DWARF 정보도 생성하지 않는다는 것을 추측할 수 있습니다.
file 결과도 비교해 볼까요?
// CGO_ENABLED=0
$ file /mnt/c/temp/testapp
[기본 옵션]
/mnt/c/temp/testapp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, with debug_info, not stripped
[-s 적용]
/mnt/c/temp/testapp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
[-w 적용]
/mnt/c/temp/testapp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
[-s, -w 2개 적용]
/mnt/c/temp/testapp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, stripped
보는 바와 같이, -s 옵션은 -s -w 2개 모두 적용했을 때와 동일하게 stripped로 나오고, -w 옵션은 "with debug_info"만을 없앤 효과를 가집니다.
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]