Microsoft MVP성태의 닷넷 이야기
개발 환경 구성: 696. C# - 리눅스용 AOT 빌드를 docker에서 수행 [링크 복사], [링크+제목 복사]
조회: 2383
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 6개 있습니다.)
개발 환경 구성: 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




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에서 빌드했을 때는 안 되는 것인지도 참 이상합니다. ^^; (혹시 이유를 아신 분은 덧글 부탁드립니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 1/14/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)
13528정성태1/14/20242033Linux: 68. busybox 컨테이너에서 실행 가능한 C++, Go 프로그램 빌드
13527정성태1/14/20241961오류 유형: 892. Visual Studio - Failed to launch debug adapter. Additional information may be available in the output window.
13526정성태1/14/20242051닷넷: 2201. C# - Facebook 연동 / 사용자 탈퇴 처리 방법
13525정성태1/13/20242021오류 유형: 891. Visual Studio - Web Application을 실행하지 못하는 IISExpress
13524정성태1/12/20242066오류 유형: 890. 한국투자증권 KIS Developers OpenAPI - GW라우팅 중 오류가 발생했습니다.
13523정성태1/12/20241889오류 유형: 889. Visual Studio - error : A project with that name is already opened in the solution.
13522정성태1/11/20242030닷넷: 2200. C# - HttpClient.PostAsJsonAsync 호출 시 "Transfer-Encoding: chunked" 대신 "Content-Length" 헤더 처리
13521정성태1/11/20242110닷넷: 2199. C# - 한국투자증권 KIS Developers OpenAPI의 WebSocket Ping, Pong 처리
13520정성태1/10/20241858오류 유형: 888. C# - Unable to resolve service for type 'Microsoft.Extensions.ObjectPool.ObjectPool`....'
13519정성태1/10/20241939닷넷: 2198. C# - Reflection을 이용한 ClientWebSocket의 Ping 호출파일 다운로드1
13518정성태1/9/20242175닷넷: 2197. C# - ClientWebSocket의 Ping, Pong 처리
13517정성태1/8/20242017스크립트: 63. Python - 공개 패키지를 이용한 위성 이미지 생성 (pystac_client, odc.stac)
13516정성태1/7/20242104닷넷: 2196. IIS - AppPool의 "Disable Overlapped Recycle" 옵션의 부작용
13515정성태1/6/20242377닷넷: 2195. async 메서드 내에서 C# 7의 discard 구문 활용 사례 [1]
13514정성태1/5/20242065개발 환경 구성: 702. IIS - AppPool의 "Disable Overlapped Recycle" 옵션
13513정성태1/5/20242006닷넷: 2194. C# - WebActivatorEx / System.Web의 PreApplicationStartMethod 특성
13512정성태1/4/20241979개발 환경 구성: 701. IIS - w3wp.exe 프로세스의 ASP.NET 런타임을 항상 Warmup 모드로 유지하는 preload Enabled 설정
13511정성태1/4/20241997닷넷: 2193. C# - ASP.NET Web Application + OpenAPI(Swashbuckle) 스펙 제공
13510정성태1/3/20241937닷넷: 2192. C# - 특정 실행 파일이 있는지 확인하는 방법 (Linux)
13509정성태1/3/20241966오류 유형: 887. .NET Core 2 이하의 프로젝트에서 System.Runtime.CompilerServices.Unsafe doesn't support netcoreapp2.0.
13508정성태1/3/20242016오류 유형: 886. ORA-28000: the account is locked
13507정성태1/2/20242702닷넷: 2191. C# - IPGlobalProperties를 이용해 netstat처럼 사용 중인 Socket 목록 구하는 방법파일 다운로드1
13506정성태12/29/20232191닷넷: 2190. C# - 닷넷 코어/5+에서 달라지는 System.Text.Encoding 지원
13505정성태12/27/20232707닷넷: 2189. C# - WebSocket 클라이언트를 닷넷으로 구현하는 예제 (System.Net.WebSockets)파일 다운로드1
13504정성태12/27/20232322닷넷: 2188. C# - ASP.NET Core SignalR로 구현하는 채팅 서비스 예제파일 다운로드1
13503정성태12/27/20232191Linux: 67. WSL 환경 + mlocate(locate) 도구의 /mnt 디렉터리 검색 문제
1  2  3  [4]  5  6  7  8  9  10  11  12  13  14  15  ...