Microsoft MVP성태의 닷넷 이야기
개발 환경 구성: 696. C# - 리눅스용 AOT 빌드를 docker에서 수행 [링크 복사], [링크+제목 복사],
조회: 10796
글쓴 사람
정성태 (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에 대한 의존성을 없애는 정적 링킹도 지원하지 않을까 싶습니다.

정성태

... 181  182  183  184  185  186  187  188  189  190  191  [192]  193  194  195  ...
NoWriterDateCnt.TitleFile(s)
142정성태4/14/200517941    답변글 VS.NET IDE: 36.1. 메모리 구성에 대한 추가 내용
137정성태3/31/200522269.NET Framework: 35. XP SP2 팝업 뚫은 소스
135정성태3/31/200520999VS.NET IDE: 26. SQL Server 2000구성이 실패
134정성태3/31/200518197COM 개체 관련: 16. Microsoft.XMLHTTP 개체에서 Microsoft.XMLDOM 개체를 전송할 때 charset 지정 문제? [2]
128정성태3/30/200516590.NET Framework: 34. VC++에서 Managed 타입의 메서드에 BSTR을 넘기는 경우의 오류(!)
129정성태3/30/200518697    답변글 .NET Framework: 34.1. 위의 질문에 대한 답변으로 나온 것입니다.
130정성태3/30/200516004        답변글 .NET Framework: 34.2. 다시... 제가 질문한 내용입니다. ^^
131정성태3/30/200516535            답변글 .NET Framework: 34.3. 다시... 정봉겸님이 하신... 명확한 답변입니다.
126정성태3/26/200516354.NET Framework: 33. Proxy 환경에서의 Smart Client 업데이트 문제 [1]
133정성태3/31/200517492    답변글 .NET Framework: 33.1. [추가]: Proxy 환경에서의 Smart Client 업데이트 문제 [2]
125정성태3/26/200516430VC++: 15. VC++ Keyword
124정성태3/25/200516988.NET Framework: 32. 네트워크 공유 없이 상대 컴퓨터에 프로그램 설치
119정성태3/21/200516551.NET Framework: 31. 소스세이프 오류현상: 웹 프로젝트를 열수 없습니다.
120정성태3/21/200517895    답변글 .NET Framework: 31.1. 소스세이프 오류현상: PDB 파일이 잠기는 문제
121정성태3/21/200517918    답변글 .NET Framework: 31.2. 소스세이프 오류현상: VS.NET 2003 IDE 와 연동되는 소스세이프 버전 문제
122정성태3/21/200516624    답변글 .NET Framework: 31.3. 소스세이프 관련 사이트
160정성태11/14/200519548    답변글 VS.NET IDE: 31.4. [추가]: 웹 애플리케이션 로드시 "_1"을 붙여서 묻는 경우. [1]
196이문석12/23/200516337        답변글 .NET Framework: 31.8. [답변]: [추가]: 웹 애플리케이션 로드시 "_1" 을 붙여서 묻는 경우.
167정성태10/10/200515906    답변글 .NET Framework: 31.5. [추가]: 삭제한 웹 가상 디렉터리에 대해 동일한 이름으로 웹 공유를 설정할 때 - 이미 있다고 오류발생
190정성태12/11/200515228    답변글 VC++: 31.6. ASP.NET 소스세이프 오류현상: 다른 사람이 체크아웃 한 것을 또 다른 사람이 체크아웃 가능!
191정성태12/11/200517690    답변글 VC++: 31.7. 소스 세이프 사용 시, 특정 프로젝트의 빌드 체크가 솔루션 로드할 때마다 해제되는 경우
118정성태3/30/200623525VC++: 14. TCP through HTTP tunneling: 기업 내 Proxy 서버 제한에서 벗어나는 방법 [2]
117정성태3/19/200524591.NET Framework: 30. Process.Start에서의 인자 길이 제한 [4]
116정성태3/14/200517094.NET Framework: 29. [.NET WebService] 자동생성되는 WSDL 을 막는 방법.
115정성태3/13/200517683VS.NET IDE: 25. [IIS 서버] ODBC 로그 남기기 [1]
195정성태12/21/200516930    답변글 VC++: 25.1. ODBC 로그를 못 남길 때의 오류 화면
... 181  182  183  184  185  186  187  188  189  190  191  [192]  193  194  195  ...