Windows 환경에서 Visual Studio를 이용한 크로스 컴파일은 결코 쉬운 일이 아닙니다. 아키텍처, 운영 체제 , 툴체인, 링커 등 여러 요소 에 따라 가능한 작업과 불가능한 작업이 달라지기 때문입니다. 이 실용적이고 상세한 가이드에서는 Visual Studio, MSBuild, CMake를 사용하여 크로스 컴파일을 구성하고 실행하는 데 필요한 모든 관련 지식을 제공합니다. 네이티브 AOT, 모바일 개발, 멀티팀 환경, Linux 환경에서의 원격 디버깅 등 다양한 시나리오를 다룹니다.
이 책의 목적은 단 한 번의 읽기로 각 기술이 지원하는 기능, 설치해야 할 Visual Studio 구성 요소 , Linux에서 종속성을 준비하는 방법, Visual Studio 없이 빌드 서버에서 필요한 경로 및 레지스트리 키, 그리고 CMake와 Visual Studio 통합을 사용하여 Windows와 Linux 간에 동일한 코드를 이동하는 방법을 이해하는 것입니다.
크로스 컴파일이란 무엇이고 네이티브 AOT의 실제 한계는 무엇인가?
크로스 컴파일이란 컴파일러가 실행되는 플랫폼과 다른 플랫폼용 바이너리를 생성하는 것을 말하며, 이는 운영 체제 또는 아키텍처의 변경 으로 인해 발생할 수 있습니다. 예를 들어, Linux에서 Windows 실행 파일을 생성하거나 x64 호스트에서 ARM64를 대상으로 하는 것이 이에 해당합니다.
네이티브 AOT를 사용하는 .NET 환경에서 컴파일된 관리 코드와 네이티브 종속성(정적 또는 동적)을 결합하기 위해 링커와 플랫폼 라이브러리가 사용됩니다 . 하지만 이로 인해 중요한 제약 사항이 발생하는데, 크로스 링커와 대상 라이브러리의 가용성에 따라 사용 가능한 운영 체제/아키텍처 조합이 결정됩니다.
현재 Windows/Linux에서 macOS 네이티브 SDK를, Linux/macOS에서 Windows SDK를, 또는 Windows/macOS에서 Linux SDK를 얻는 표준화되고 지원되는 방법은 없습니다. 따라서 네이티브 AOT는 운영 체제 간 크로스 컴파일을 지원하지 않습니다. 서로 다른 운영 체제 간 컴파일이 필요한 경우 , 실질적인 해결책은 에뮬레이션, 가상 머신 또는 Windows의 WSL을 사용하는 것입니다.
동일한 운영 체제 내에서 아키텍처 간 크로스 컴파일이 가능한 영역은 바로 크로스 컴파일입니다. 적절한 툴체인을 설치하면 Windows, macOS 또는 Linux에서 x64와 ARM64 간 크로스 컴파일이 가능합니다 . 이는 x64 데스크톱 호스트에서 ARM64 바이너리를 생성하려는 가장 일반적인 시나리오입니다.
시스템 요구 사항 및 도구: Windows, macOS 및 Linux
크로스 컴파일을 성공적으로 수행하려면 적절한 네이티브 툴체인 과 해당 유틸리티(링커, objcopy/strip, C 런타임, zlib 등)를 설치해야 합니다 . 이러한 툴체인의 가용성은 운영 체제 및 배포판에 따라 다릅니다.
Windows (x64 ↔ ARM64) . Windows x64에서 Windows ARM64로 (또는 그 반대로) 크로스 컴파일하려면 올바른 Visual Studio 2022 C++ 빌드 도구를 설치해야 합니다. 대상이 ARM64인 경우 "VS 2022 C++ ARM64/ARM64EC 빌드 도구(최신)" 구성 요소를 포함해야 합니다. 대상이 x64인 경우 "Visual Studio 2022 C++ x64/x86 빌드 도구(최신)" 구성 요소를 찾으십시오.
macOS 환경 에서는 Xcode에 기본적으로 x64 및 ARM64 툴체인이 포함되어 있으므로 표준 설치만으로 두 아키텍처 모두를 대상으로 개발할 수 있습니다. 또한, 이 환경에서는 Visual Studio for Mac 과 CMake도 이러한 Apple 툴체인을 사용합니다.
Linux각 배포판은 네이티브 종속성을 다르게 처리합니다. 최소한 다음이 필요합니다. 대상에 출력할 수 있는 링커(예: 그 소리), 유틸리티 objcopy/strip 활성화하면 대상과 호환됩니다. StripSymbols, 그리고 객체 C 런타임 과 ZLIB 대상 아키텍처에 대해서.
Ubuntu 22.04 amd64에서는 다음과 같습니다. 명령 충분할 수도 있습니다 linux-arm64 (Ubuntu에서 문서화되거나 보장되지는 않지만 일반적으로 작동합니다):
sudo dpkg --add-architecture arm64
sudo bash -c 'cat > /etc/apt/sources.list.d/arm64.list <<EOF
deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports/ jammy main restricted
deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports/ jammy-updates main restricted
deb [arch=arm64] http://ports.ubuntu.com/ubuntu-ports/ jammy-backports main restricted universe multiverse
EOF'
sudo sed -i -e 's/deb http/deb [arch=amd64] http/g' /etc/apt/sources.list
sudo sed -i -e 's/deb mirror/deb [arch=amd64] mirror/g' /etc/apt/sources.list
sudo apt update
sudo apt install -y clang llvm binutils-aarch64-linux-gnu gcc-aarch64-linux-gnu zlib1g-dev:arm64
Visual Studio를 사용한 크로스 플랫폼 개발: 모바일, 게임 및 UWP
Visual Studio는 데스크톱에만 국한되지 않습니다. C#, .NET, C++, 심지어 HTML/JS를 사용하여 Android , iOS 및 Windows 용 앱을 만들 수 있습니다 . 프로젝트 간에 코드, 문자열 및 리소스를 공유할 수 있으며, Xamarin.Forms와 같은 프레임워크를 사용하면 인터페이스까지도 공유할 수 있습니다.
Android, iOS 또는 Windows 플랫폼을 대상으로 .NET을 사용하는 경우 " 모바일 개발 (Xamarin) " 옵션을 설치하세요. 전용 프로젝트 템플릿, 네이티브 API에 대한 완벽한 접근 권한, Visual Studio의 생산성 향상 기능(디자이너, IntelliSense, 에뮬레이터, 연결된 기기에서의 실행)을 이용할 수 있습니다. 또한 Xamarin.Forms를 사용하면 각 플랫폼에서 네이티브로 렌더링되는 공통 UI를 정의할 수 있습니다.
게임 및 몰입형 그래픽 개발을 위해 Visual Studio는 C# 스크립트 편집 및 디버깅 기능을 통합한 Unity용 도구(VSTU)를 제공합니다 . 최신 버전은 Unity 2019.4 지원, ShaderLab 색상 지원, 향상된 동기화 기능, 더욱 포괄적인 디버깅 기능, 그리고 MonoBehavior용 코드 생성 기능 개선을 제공합니다.
단일 앱과 반응형 인터페이스 모델로 다양한 Windows 10 장치를 대상으로 하려면 UWP 애플리케이션을 만들 수 있습니다 . Visual Studio의 UWP 템플릿을 사용하면 시각적으로 디자인하고, 다양한 폼 팩터에 맞춰 미리 보고, 도구 모음에서 에뮬레이터와 시뮬레이터를 쉽게 선택할 수 있습니다.
서버에서 Visual Studio 없이 빌드 환경: 다중 머신
기업 환경에서는 Visual Studio 정식 라이선스 없이 빌드 서버가 필요한 경우가 흔합니다. 호스트 컴퓨터에 Visual Studio를 설치하고 파일과 구성을 빌드 서버로 복사하여 내부 빌드 환경을 구축할 수 있습니다. 하지만 이렇게 한다고 해서 소프트웨어를 외부로 재배포하거나 제3자에게 빌드 환경을 제공할 권한이 생기는 것은 아닙니다.
참고로, 이 문서에서는 Windows 8(x86/x64), Windows 7 Ultimate, Windows Server 2008 R2 Standard 와 같은 시스템에서 이러한 단계를 테스트했습니다 . 이 과정을 완료하면 Windows 8 SDK를 사용하여 C++ 데스크톱 앱을 컴파일하거나 .NET Framework 4.5용 VB/C# 앱을 컴파일할 수 있습니다. 단, UWP 또는 .NET Framework 4.0 이하 버전에서는 추가 도구 없이는 작동하지 않습니다.
필수 조건 : 호스트에 ".NET 데스크톱 개발" 워크로드가 포함된 Visual Studio가 설치되어 있어야 합니다. 빌드 머신에는 .NET Framework 4.5 이상이 설치되어 있어야 합니다 (레지스트리 키 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\Version을 확인하십시오).
Windows SDK 및 도구를 복사합니다 . 기본 설치 경로(%ProgramFiles%)에서 시작하여 다음 폴더를 빌드 머신으로 재귀적으로 복사합니다. Windows Kits 8.0(bin, Catalogs, DesignTime, include, Lib, Redist, References), Microsoft SDKs Windows v8.0A(NETFX 4.0 도구), Common Files\Merge Modules, 그리고 주요 VC 및 MSBuild 디렉터리 등이 포함됩니다 . 특히 WDk/ADK를 사용하는 경우, 설치된 각 키트의 라이선스 약관을 준수해야 합니다.
또한 msobj110.dll, mspdb110.dll, mspdbcore.dll, mspdbsrv.exe, msvcdis110.dll, makehm.exe, VCVarsQueryRegistry.bat 및 vsvars32.bat 과 같은 특정 파일들을 이동합니다 . 빌드 서버에서 바이너리(예: 테스트)를 실행하기 위해 아키텍처에 따라 Visual C++ 런타임 (msvcp110.dll, msvcr110.dll, atl110.dll, vcamp110.dll 등)을 System32/SysWOW64로 복사하고, Debug_NonRedist에서 디버그 변형(msvcp110d.dll, msvcr110d.dll 등)을 복사합니다.
필수 레지스트리 키 . MSBuild 값을 구성하려면 항목을 생성해야 합니다. 루트는 아키텍처에 따라 다릅니다. x86 아키텍처에서는 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft이고, x64 아키텍처에서는 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft입니다(이하 %RegistryRoot%). 호스트의 값을 반영하여 다음 문자열(REG_SZ) 항목을 생성하십시오.
%RegistryRoot%\.NETFramework\v4.0.30319\AssemblyFoldersEx\VCMSBuild Public Assemblies@(Default)
%RegistryRoot%\Microsoft SDKs\Windows\v8.0@InstallationFolder
%RegistryRoot%\Microsoft SDKs\Windows\v8.0A@InstallationFolder
%RegistryRoot%\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools@InstallationFolder
%RegistryRoot%\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x86@InstallationFolder
%RegistryRoot%\VisualStudio\11.0@Source Directories
%RegistryRoot%\VisualStudio\11.0\Setup\VC@ProductDir
%RegistryRoot%\VisualStudio\SxS\VC7@FrameworkDir32
%RegistryRoot%\VisualStudio\SxS\VC7@FrameworkDir64
%RegistryRoot%\VisualStudio\SxS\VC7@FrameworkVer32
%RegistryRoot%\VisualStudio\SxS\VC7@FrameworkVer64
%RegistryRoot%\VisualStudio\SxS\[email protected]
%RegistryRoot%\VisualStudio\SxS\[email protected]
%RegistryRoot%\Windows Kits\Installed Roots@KitsRoot
%RegistryRoot%\MSBuild\ToolsVersions\4.0\11.0@VCTargetsPath
%RegistryRoot%\MSBuild\ToolsVersions\4.0\11.0@VCTargetsPath10
%RegistryRoot%\MSBuild\ToolsVersions\4.0\11.0@VCTargetsPath11x64 시스템에서는 %RegistryRoot%\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx40Tools-x64@InstallationFolder 도 추가하십시오 . 네이티브 64비트 MSBuild(또는 x64에서 TFS 빌드 서비스)를 사용하는 경우 네이티브 64비트 레지스트리에 다음 항목을 추가하십시오. HKLM\SOFTWARE\Microsoft\VisualStudio\11.0\Setup\VS@ProductDir 및 HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\11.0 의 VCTargetsPath, VCTargetsPath10, VCTargetsPath11 세 가지 값 .
환경 변수직접적인 방법은 실행하는 것입니다 vcvarsall.bat 부터 …\VC\vcvarsall.bat대상 툴체인을 인수로 지정할 수 있습니다. 생략하면 x86이 사용됩니다. 주요 인수는 다음과 같습니다.
| 인수 | 컴파일러 유형 | 주인 | 목적지 |
|---|---|---|---|
| x86 | 네이티브 32비트 | x86, x64 | x86 |
| x86_amd64 | x64로의 크로스오버 | x86, x64 | x64 |
| amd64 | 네이티브 64비트 | x64 | x64 |
원하시면 조정할 수 있습니다 PATH 수동 적절한 경우 Common7\IDE 및 32/64비트 MSBuild 디렉터리에 대한 경로를 추가합니다. vcvarsall.bat 그러면 잊어버리는 일이 없어집니다.
MSBuild 어셈블리용 GACMSBuild가 GAC에 필요로 하는 추가 어셈블리가 있습니다. 호스트에서 빌드 서버의 아무 폴더로나 복사하고 등록하세요. gacutil -i (당신은 그것을 찾을 수 있습니다 Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 도구):
%ProgramFiles%\MSBuild\Microsoft.Cpp\v4.0\v110\Microsoft.Build.CPPTasks.Common.v110.dll
%ProgramFiles%\Microsoft Visual Studio\<versión>\<edición>\Common7\IDE\CommonExtensions\Microsoft\VC\Project\Microsoft.VisualStudio.Project.VisualC.VCProjectEngine.dll
%ProgramFiles%\Microsoft Visual Studio\<versión>\<edición>\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.VCProjectEngine.dll편집. 서버 명령줄에서 다음을 호출할 수 있습니다. msbuild 직접 또는 프로세스를 통합 Azure 파이프 라인에이전트의 아키텍처와 일치하는 MSBuild 실행 파일을 자동으로 선택합니다. 기본적인 예는 다음과 같습니다. msbuild solution.sln.
이식 가능하고 버전 관리되는 소스 제어 환경이 필요한 경우, 디렉터리를 %Depot%에 복사하여 " Depot "을 생성하고 MSBuild 파일(Microsoft.CPP.Targets 등)을 수정하여 GAC 대신 AssemblyFile="$(VCTargetsPath11)Microsoft.Build.CppTasks.Common.v110.dll"을 참조하도록 할 수 있습니다. 또한 각 프로젝트 시작 시 VCTargetsPath, MSBuildExtensionsPath, VCInstallDir 및 WindowsSdkDir 과 같은 속성을 포함하는 Partner.AutoImports.props 파일을 가져와야 합니다.
MSBuild, CMake 및 파이프라인: 지원되는 빌드 방법
Visual Studio는 IDE에서 컴파일할 수 있을 뿐만 아니라, CLI의 MSBuild , CMake 및 Azure Pipelines를 사용해서도 컴파일할 수 있습니다 . 각 방법에는 장점이 있습니다.
- IDE: 즉각적인 빌드, 통합 디버깅, 멀티스레드 컴파일 및 주요 사용자 정의 기능.
- CMake: .vcxproj 프로젝트 없이 Linux와 Windows 간의 C++ 빌드 시스템을 통합합니다. 기반이 이미 CMake인 경우에 이상적입니다.
- MSBuild(CLI): Visual Studio 전체를 설치하지 않고도 컴파일하고, 속성과 대상을 통해 병렬 빌드와 광범위한 사용자 정의가 가능합니다.
- Azure 파이프 라인: CI/CD를 통합하고, 자동화된 테스트를 실행하고, 높은 수준의 사용자 정의가 가능한 작업으로 클라우드에서 확장합니다.
IDE 내에서 플랫폼(Windows 또는 Linux) 및 모드(디버그/릴리스)별로 출력 디렉터리, 빌드 후 이벤트 , 프로젝트 종속성, 로그 및 경고 억제와 같은 옵션을 조정할 수 있습니다. 이러한 유연성은 단일 솔루션 내에서 여러 아키텍처 또는 툴체인을 관리할 때 필수적입니다 .
CMake 흐름: Visual Studio에서 Windows 및 Linux에서 빌드 및 디버깅
CMake를 사용하는 C++ 빌드의 경우 Visual Studio를 사용하면 repo 폴더를 쉽게 열 수 있습니다. CMakeLists.txt), 캐시를 자동으로 생성하고 구성합니다. 대상별 IntelliSense. 거기에서 지속되는 명시적 구성(예: x64-Debug)을 만들 수 있습니다. CMakeSettings.json.
일반적인 흐름은 예를 들어 프로젝트 복제로 시작됩니다. git clone https://github.com/bulletphysics/bullet3.gitVisual Studio에서 루트 CMakeLists를 열고 캐시를 생성한 후 라이브러리와 실행 파일이 있는 "CMake Targets View"가 표시됩니다.
Windows에서 디버깅하려면 대상 실행 파일을 선택하세요(예: AppBasicExampleGui.exe Bullet SDK에서), 중단점을 설정하다 주요 기능(예: mouseButtonCallback)을 누르고 F5 키를 눌러 시작하세요. 내장 디버거를 사용하여 변수, 객체, 스레드 및 메모리를 검사할 수 있습니다.
Linux의 경우 설정을 추가하세요.Linux-디버그» CMakeSettings에서 해당되는 경우 "Unix Makefiles" 생성기를 선택하고 SSH를 통해 원격 컴퓨터에 연결합니다(Visual Studio 관리). ssh/rsync, gdb, make 및 Linux 호스트의 CMake). 일반적인 도구가 필요합니다(build-essential, gdb, rsync, make, zip) 및 최신 버전의 CMake(최소 3.8; Microsoft는 설치할 수 있는 범용 바이너리를 제공합니다. --prefix=/usr).
앱이 Linux의 데스크톱 앱인 경우 내보내야 할 수도 있습니다. DISPLAY. 가치를 얻으세요 echo $DISPLAY 그리고 추가한다 launch.vs.json 구성에서 해당 접두사가 pipeArgs: 예를 들어, "export DISPLAY=:1;${debuggerCommand}" 그것을 확인하기 위해 gdb 올바른 그래픽 컨텍스트에서 시작하세요.
바이너리가 원격 컴퓨터에서 실행되면 중단점에 도달하면 Visual Studio가 바이너리를 포그라운드로 가져와서 표시합니다. 호출 스택 (예를 들어, 다음과 같은 콜백 CommonRigidBodyBase::mouseMoveCallback, X11OpenGLWindow::pumpMessage, 등). 또한 원격 출력이 있는 콘솔이 표시되며 필요한 경우 표준 입력을 보낼 수 있습니다.
이 접근 방식을 사용하면 Windows와 Linux 모두에서 단일 IDE를 사용하여 동일한 소스 코드, 다양한 툴체인 및 일관된 디버깅 환경을 유지하면서 반복 작업을 수행할 수 있습니다.
추가 참고 사항 및 고려 사항
공식적인 제한 사항을 유념하십시오. 네이티브 AOT는 가상화/에뮬레이션 없이는 OS 간 호환성을 지원하지 않지만 , 올바른 툴체인을 사용하면 동일한 OS 내에서 아키텍처를 교환(x64 ↔ ARM64)할 수 있습니다. Linux에서는 StripSymbols를 활성화한 경우 사용하는 objcopy/strip 유틸리티가 대상을 지원하는지 확인하십시오.
서버 환경에서는 복사하는 각 구성 요소(Windows 키트, WDK, ADK 등)의 라이선스 약관을 검토하십시오. Microsoft는 이러한 가이드가 "있는 그대로" 제공되며 모든 가능한 구성에서 단계가 테스트될 수 없음을 경고합니다. 따라서 표준화하기 전에 사용 환경에서 파이프라인을 검증하는 것이 좋습니다.
마지막으로, 동일한 솔루션에서 여러 플랫폼을 구성할 때는 구성 및 출력 파일의 이름을 잘 지정하고 구분해야 합니다 (예: 아키텍처/OS별로 다른 폴더 사용). MSBuild를 사용하여 자동화하고, 가능하다면 Azure Pipelines를 통해 모든 것을 CI/CD 파이프라인 에 통합하여 반복성과 추적성을 확보하십시오.
적절한 툴체인, 세심한 MSBuild/CMake 구성, 그리고 IDE 지원만 있다면, Windows에서 다양한 아키텍처용 바이너리를 생성하고, VS 없이도 서버에서 빌드를 오케스트레이션하며, 혼합된 팀에서 균일하고 생산적인 디버깅 환경을 통해 동일한 코드를 Windows와 Linux 간에 이동할 수 있습니다.
바이트와 기술 전반에 관한 세계에 대한 열정적인 작가입니다. 나는 글쓰기를 통해 내 지식을 공유하는 것을 좋아하며 이것이 바로 이 블로그에서 할 일이며 가젯, 소프트웨어, 하드웨어, 기술 동향 등에 관한 가장 흥미로운 모든 것을 보여 드리겠습니다. 제 목표는 여러분이 간단하고 재미있는 방식으로 디지털 세계를 탐색할 수 있도록 돕는 것입니다.