Microsoft MVP성태의 닷넷 이야기
개발 환경 구성: 696. C# - 리눅스용 AOT 빌드를 docker에서 수행 [링크 복사], [링크+제목 복사],
조회: 5370
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 2개 있습니다.)
(시리즈 글이 7개 있습니다.)
개발 환경 구성: 386. .NET Framework Native compiler 프리뷰 버전 사용법
; https://www.sysnet.pe.kr/2/0/11563

.NET Framework: 2069. .NET 7 - AOT(ahead-of-time) 컴파일
; https://www.sysnet.pe.kr/2/0/13162

닷넷: 2175. C# - DllImport 메서드의 AOT 지원을 위한 LibraryImport 옵션
; https://www.sysnet.pe.kr/2/0/13466

닷넷: 2184. C# - 하나의 resource 파일을 여러 프로그램에서 (AOT 시에도) 사용하는 방법
; https://www.sysnet.pe.kr/2/0/13483

개발 환경 구성: 696. C# - 리눅스용 AOT 빌드를 docker에서 수행
; https://www.sysnet.pe.kr/2/0/13487

닷넷: 2202. C# - PublishAot의 glibc에 대한 정적 링킹하는 방법
; https://www.sysnet.pe.kr/2/0/13529

오류 유형: 913. C# - AOT StaticExecutable 정적 링킹 시 빌드 오류
; https://www.sysnet.pe.kr/2/0/13669




C# - 리눅스용 AOT 빌드를 docker에서 수행

현재 AOT 빌드는 해당 플랫폼 환경에서만 할 수 있습니다. 간단하게 실습하면서 설명해 볼까요? ^^ 예제로 Console App을 하나 구성하고,

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
    <PublishAot>true</PublishAot>
    <InvariantGlobalization>true</InvariantGlobalization>
  </PropertyGroup>

</Project>

using System.Runtime.InteropServices;

namespace ConsoleApp1;

internal class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine($"{Environment.OSVersion}, {RuntimeEnvironment.GetSystemVersion()}");
    }
}

(윈도우 머신에서) 리눅스를 대상으로 AOT 빌드를 하면 이런 오류가 발생합니다.

c:\temp\ConsoleApp1\ConsoleApp1> dotnet publish -r linux-x64 -c Release
MSBuild version 17.8.3+195e7f5a3 for .NET
  Determining projects to restore...
  Restored C:\temp\ConsoleApp1\ConsoleApp1\ConsoleApp1.csproj (in 3.6 sec).
  ConsoleApp1 -> C:\temp\ConsoleApp1\ConsoleApp1\bin\Release\net8.0\linux-x64\ConsoleApp1.dll
C:\...[생략]...\Microsoft.NETCore.Native.Publish.targets(60,5): error : Cross-OS native compilation is not supported. [C:\temp\ConsoleApp1\ConsoleApp1\ConsoleApp1.csproj]

즉, Linux 환경에서 해야 한다는 것이고 간편하게는 WSL 환경에서 /mnt 경로를 이용해 빌드하는 것도 좋은 선택입니다.




WSL을 이용하는 경우 shell을 이동해야 한다는 불편함을 수반하는데요, 그렇다면 wsl.exe를 이용해 다음과 같이 처리하는 것도 가능합니다.

C:\temp> wsl /bin/bash -c "cd /mnt/c/temp/ConsoleApp1/ConsoleApp1 && dotnet publish -r linux-x64 -c Release"

혹은, docker를 이용해 해결하는 것도 가능합니다. 이런 경우 약간 준비할 것이 있는데요, 우선, Native 빌드 환경을 위해 전용 빌드 이미지를 하나 만들어야 합니다. 대략 요구되는 dockerfile은 아래와 같은 정도면 충분합니다.

c:\temp> type publish.dockerfile
FROM mcr.microsoft.com/dotnet/sdk:8.0

RUN apt-get update && apt-get install -y --no-install-recommends clang zlib1g-dev

그다음, 재사용할 이미지로 생성해 두고,

c:\temp> docker build -t net80-native-build-machine -f publish.dockerfile .

이후, dotnet publish가 필요할 때마다 다음과 같이 실행해 줍니다.

c:\temp> SET PROJECT_DIR=/C/temp/ConsoleApp1/ConsoleApp1

c:\temp> docker rm -f net80-native-build-machine-instance

c:\temp> docker run -v %PROJECT_DIR%:/app --name net80-native-build-machine-instance --rm -it net80-native-build-machine /bin/bash -c "cd /app && dotnet publish -r linux-x64 -c Release"

그럼, C:\temp\ConsoleApp1\ConsoleApp1\bin\Release\net8.0\linux-x64\publish 디렉터리에 linux-x64용으로 빌드된 결과가 생성됩니다.




그런데, 이렇게 빌드한 실행 파일을 Ubuntu 20.04에서 실행하면 이런 오류 메시지가 발생하는군요. ^^;

// WSL + Ubuntu 20.04에서 실행

$ ./ConsoleApp1
./ConsoleApp1: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by ./ConsoleApp1)
./ConsoleApp1: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./ConsoleApp1)

$ ldd --version
ldd (Ubuntu GLIBC 2.31-0ubuntu9.14) 2.31

반면 22.04에서는 잘됩니다.

// WSL + Ubuntu 22.04에서 실행

$ ./ConsoleApp1
Unix 5.15.133.1, v8.0.0

$ ldd --version
ldd (Ubuntu GLIBC 2.35-0ubuntu3.5) 2.35

$ objdump -p ConsoleApp1

ConsoleApp1:     file format elf64-x86-64

...[생략]...

Dynamic Section:
  NEEDED               libm.so.6
  NEEDED               libc.so.6
  NEEDED               ld-linux-x86-64.so.2
...[생략]...

Version References:
  required from ld-linux-x86-64.so.2:
    0x0d696913 0x00 14 GLIBC_2.3
  required from libm.so.6:
    0x06969189 0x00 15 GLIBC_2.29
    0x09691a75 0x00 06 GLIBC_2.2.5
  required from libc.so.6:
    0x06969190 0x00 13 GLIBC_2.10
    0x09691974 0x00 12 GLIBC_2.3.4
    0x0d696914 0x00 11 GLIBC_2.4
    0x06969197 0x00 10 GLIBC_2.17
    0x06969194 0x00 09 GLIBC_2.14
    0x069691b2 0x00 08 GLIBC_2.32
    0x0d696919 0x00 07 GLIBC_2.9
    0x0d696916 0x00 05 GLIBC_2.6
    0x069691b4 0x00 04 GLIBC_2.34
    0x09691a75 0x00 03 GLIBC_2.2.5
    0x09691972 0x00 02 GLIBC_2.3.2

검색해 보면,

GLIBC_2.32 not found
; https://copyprogramming.com/howto/glibc-2-32-not-found

Ubuntu 20.10부터 2.32 버전이 제공된다고 합니다. 그러니까... "mcr.microsoft.com/dotnet/sdk:8.0" 이미지가 그 버전 이상의 리눅스 이미지를 기반으로 한다는 것인데요, 다소 번거롭지만 이런 문제를 해결하려면 dockerfile을 다음과 같이 구성해야 합니다.

FROM ubuntu:20.04

RUN apt-get update
RUN apt-get install -y wget

RUN wget https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
RUN dpkg -i packages-microsoft-prod.deb
RUN rm packages-microsoft-prod.deb

RUN apt-get update
RUN apt-get install -y dotnet-sdk-8.0
RUN apt-get install -y --no-install-recommends clang zlib1g-dev

저 dockerfile로 다시 빌드를 하면 이제 GLIBC 버전 문제는 없어집니다. 즉, Ubuntu 20.04, 22.04에서도 잘 동작합니다. 혹시 리눅스 전문가가 계신다면 이에 대한 이유를 좀 알 수 있을까요? 리눅스 계열에서는 GLIBC를 하위 호환성을 지키기 때문에 그런 것인지, 아니면 이전 버전을 모두 유지해서 포함시켜 두기 때문에 괜찮은 것인지, 그 이유를 잘 모르겠습니다. (glibc는 하위 호환성이 있어 낮은 버전과 링크하는 경우에는 범용성이 좋아진다고 합니다.)




다시 예상할 수 있듯이, 이제는 ubuntu 18에서 유사한 오류가 발생합니다.

$ ./ConsoleApp1
./ConsoleApp1: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./ConsoleApp1)

그런데 아쉽게도 .NET 8의 공식 리눅스 지원 버전이 Ubuntu로는 20.04+라고 명시돼 있는데요,

.NET 8 - Supported OS versions - Linux
; https://github.com/dotnet/core/blob/main/release-notes/8.0/supported-os.md#linux

재미있는 건 18.04에서도 설치 및 실행이 모두 잘됩니다. ^^ 따라서 다음과 같이 이미지 버전만 바꿔주고,

FROM ubuntu:18.04

RUN apt-get update
RUN apt-get install -y wget

RUN wget https://packages.microsoft.com/config/ubuntu/20.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
RUN dpkg -i packages-microsoft-prod.deb
RUN rm packages-microsoft-prod.deb

RUN apt-get update
RUN apt-get install -y dotnet-sdk-8.0
RUN apt-get install -y --no-install-recommends clang zlib1g-dev

AOT 빌드하면 Ubuntu 18.04 ~ 22.04에서 잘 동작하고 심지어 CentOS 7에서도 정상적으로 실행됩니다.
// docker ubuntu:18.04 환경에서 실행
$  ldd --version
ldd (Ubuntu GLIBC 2.27-3ubuntu1.6) 2.27
...[생략]...

// CentOS 7 환경에서 실행
$ ldd --version
ldd (GNU libc) 2.17
...[생략]...

$ lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch
Distributor ID: CentOS
Description:    CentOS Linux release 7.6.1810 (Core) 
Release:        7.6.1810
Codename:       Core

$ ./ConsoleApp1
Unix 5.1.15.1, v8.0.0

왜냐하면, 이렇게 빌드했을 때의 링크된 버전을 보면,

$ objdump -p ConsoleApp1
...[생략]...
Version References:
  required from ld-linux-x86-64.so.2:
    0x0d696913 0x00 18 GLIBC_2.3
  required from libdl.so.2:
    0x09691a75 0x00 11 GLIBC_2.2.5
  required from librt.so.1:
    0x09691a75 0x00 10 GLIBC_2.2.5
  required from libm.so.6:
    0x09691a75 0x00 06 GLIBC_2.2.5
  required from libc.so.6:
    0x06969196 0x00 19 GLIBC_2.16
    0x06969190 0x00 17 GLIBC_2.10
    0x09691974 0x00 16 GLIBC_2.3.4
    0x0d696914 0x00 15 GLIBC_2.4
    0x06969194 0x00 13 GLIBC_2.14
    0x0d696919 0x00 12 GLIBC_2.9
    0x09691972 0x00 09 GLIBC_2.3.2
    0x0d696913 0x00 07 GLIBC_2.3
    0x0d696916 0x00 05 GLIBC_2.6
    0x09691a75 0x00 03 GLIBC_2.2.5
  required from libpthread.so.0:
    0x09691973 0x00 14 GLIBC_2.3.3
    0x06969192 0x00 08 GLIBC_2.12
    0x09691a75 0x00 04 GLIBC_2.2.5
    0x09691972 0x00 02 GLIBC_2.3.2

보는 바와 같이 2.16 버전이 최고입니다.





마지막으로, 당연히 위와 같은 문제는 WSL을 경유한 빌드에서도 동일하게 발생합니다. wsl을 그냥 실행하는 경우 "Default"로 지정한 인스턴스에 명령을 전달하기 때문에,

c:\temp> wsl -l
Linux용 Windows 하위 시스템 배포:
Ubuntu-20.04(기본값)
Ubuntu-18.04
docker-desktop-data
docker-desktop

따라서, 다음과 같이 배포본 이름을 지정해 빌드를 해야 합니다.

C:\temp> wsl -d Ubuntu-18.04 --exec ldd --version
ldd (Ubuntu GLIBC 2.27-3ubuntu1.6) 2.27
...[생략]...

C:\temp> wsl -d Ubuntu-18.04 --exec lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.6 LTS
Release:        18.04
Codename:       bionic

C:\temp> wsl -d Ubuntu-18.04 --exec /bin/bash -c "cd /mnt/c/temp/ConsoleApp1/ConsoleApp1 && dotnet publish -r linux-x64 -c Release"

그런데, 이상한 점이 있는데요, WSL에 설치되는 Ubuntu 18.04에서 AOT 빌드한 결과물은 해당 환경에서 빌드했음에도 불구하고 실행이 안 됩니다.

$ ./ConsoleApp1
./ConsoleApp1: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29' not found (required by ./ConsoleApp1)

18.04의 GLIBC 환경이 2.27로 2.29보다 더 낮은 환경이었는데 저렇게 실행이 안 되는 것입니다. docker 환경에서 빌드했을 때는 괜찮았는데, 왜 WSL + Ubuntu 18.04에서 빌드했을 때는 안 되는 것인지도 참 이상합니다. ^^; (혹시 이유를 아신 분은 덧글 부탁드립니다.)




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/13/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2023-12-18 09시39분
Using Native AOT
; https://github.com/dotnet/runtime/tree/main/src/coreclr/nativeaot/docs

Building native AOT apps in containers
; https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/docs/containers.md

---------------------------------------------------------
아래와 같은 노력과,

Compiling with Native AOT
; https://github.com/dotnet/runtime/blob/main/src/coreclr/nativeaot/docs/compiling.md#using-statically-linked-icu

StaticallyLinked 옵션 등이 있었던 것을 보면,

Statically Linked NativeAOT HelloWorld throws Segmentation fault with Globalization Cultural Data #70848
; https://github.com/dotnet/runtime/issues/70848

아마도 향후에는 glibc에 대한 의존성을 없애는 정적 링킹도 지원하지 않을까 싶습니다.

정성태

1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13684정성태7/19/20242935닷넷: 2279. C# - 문자열 보간식 사례
13683정성태7/18/20243115오류 유형: 917. ClrMD - Linux 환경의 .NET 5 덤프 분석 시 hang 현상
13682정성태7/18/20243049닷넷: 2278. WPF - 스레드에 종속되는 DependencyObject파일 다운로드1
13681정성태7/17/20242724닷넷: 2277. C# 13 - (2) 메서드 그룹의 자연 타입 개선 (메서드 추론 개선)파일 다운로드1
13680정성태7/16/20242479닷넷: 2276. C# - Method Group, Natural Type, function_type파일 다운로드1
13679정성태7/16/20242498Linux: 76. Linux - C++ (getaddrinfo 등을 담고 있는) libnss 정적 링크
13678정성태7/15/20242358VS.NET IDE: 191. Visual Studio 2022 - .NET 5 프로젝트를 Docker Support로 실행했을 때 오류
13677정성태7/15/20242341오류 유형: 916. MSBuild - CheckEolTargetFramework (warning NETSDK1138)
13676정성태7/14/20242476Linux: 75. gdb에서 glibc의 함수에 Breakpoint 걸기
13675정성태7/13/20243556C/C++: 166. C/C++ - DLL에서 template 함수를 export하는 방법 [1]파일 다운로드1
13674정성태7/13/20242815오류 유형: 915. Unhandled Exception: Microsoft.Diagnostics.NETCore.Client.ServerNotAvailableException: Unable to connect to Process
13673정성태7/11/20242913닷넷: 2275. C# 13 - (1) 신규 이스케이프 시퀀스 '\e'파일 다운로드1
13672정성태7/10/20242880닷넷: 2274. IIS - (프로세스 종료 없는) AppDomain Recycle
13671정성태7/10/20242750오류 유형: 914. Package ca-certificates is not installed.
13669정성태7/9/20242832오류 유형: 913. C# - AOT StaticExecutable 정적 링킹 시 빌드 오류
13668정성태7/8/20242901개발 환경 구성: 716. Hyper-V - Ubuntu 22.04 Generation 2 유형의 VM 설치
13667정성태7/7/20242525닷넷: 2273. C# - 리눅스 환경에서의 Hyper-V Socket 연동 (AF_VSOCK)파일 다운로드1
13666정성태7/7/20243079Linux: 74. C++ - Vsock 예제 (Hyper-V Socket 연동)파일 다운로드1
13665정성태7/6/20243229Linux: 73. Linux 측의 socat을 이용한 Hyper-V 호스트와의 vsock 테스트파일 다운로드1
13663정성태7/5/20242989닷넷: 2272. C# - Hyper-V Socket 통신(AF_HYPERV, AF_VSOCK)의 VMID Wildcards 유형파일 다운로드1
13662정성태7/4/20243401닷넷: 2271. C# - WSL 2 VM의 VM ID를 알아내는 방법 - Host Compute System API파일 다운로드1
13661정성태7/3/20242940Linux: 72. g++ - 다른 버전의 GLIBC로 소스코드 빌드
13660정성태7/3/20242954오류 유형: 912. Visual C++ - Linux 프로젝트 빌드 오류
13659정성태7/1/20243144개발 환경 구성: 715. Windows - WSL 2 환경의 Docker Desktop 네트워크
13658정성태6/28/20243145개발 환경 구성: 714. WSL 2 인스턴스와 호스트 측의 Hyper-V에 운영 중인 VM과 네트워크 연결을 하는 방법 - 두 번째 이야기
13657정성태6/27/20243451닷넷: 2270. C# - Hyper-V Socket 통신(AF_HYPERV, AF_VSOCK)을 위한 EndPoint 사용자 정의
1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...