이것은 흥미로운 소식입니다. 작동 가능한 Itanium Merced 에뮬레이션이 포함된 Qemu의 포크(fork)가 존재하며, 이는 Windows XP/2003을 실행하기에 충분할 정도로 성능이 좋습니다! 바로 Malte Kuhlmann의 Qemu 포크이며, 이는 syunnPC의 AI Itanium이 주입된 Qemu 포크를 기반으로 합니다.

언젠가는 어떤 종류의 병합(merger)이 일어날 것이라고 확신합니다. 언제나 그렇듯, 흥미로운 일들은 빠르게 진행됩니다.

어쨌든, 저는 이것을 빌드(build)하는 과정에서 엄청난 문제들을 겪었습니다. Alph64 Windows를 실행할 수 있는 Qemu Alpha를 위한 단계들을 기록해 두었어야 했습니다! ...하지만 그러지 못했고, 그래서 필요한 레시피(recipes)를 (잠시 동안이지만) 잃어버린 셈이 되었습니다.

대신, 저는 다시 제 Mac mini로 돌아가고 있습니다. 당연하게도 macOS는 유용할 만큼 충분한 UNIX이면서도, 실제 애플리케이션을 사용할 수 있을 만큼 주류이기 때문입니다. 그리고 그 이유 중 하나는 펌웨어(firmware)를 직접 빌드하고 싶었기 때문인데, 제가 놓치고 있는 어떤 중요한 '락스텝(lockstep)' 요소가 있을 것 같다는 느낌이 들었기 때문입니다.

교차 컴파일러(cross compilers)를 빌드하는 것은 저나 이 블로그에 있어 그리 새로운 일은 아닙니다. 사실, 현재 다른 여러 프로젝트를 통해 두 개를 가지고 있습니다:

jsteve@Jasons-Mac-mini gcc % /usr/local/os2/bin/i386-pc-linux-gnuaout-gcc -v
Reading specs from /usr/local/os2/lib/gcc-lib/i386-pc-linux-gnuaout/2.8.1/specs
gcc version 2.8.1
...

GCC 2.8.1은 i386으로 교차 컴파일하기 위한 macOS arm64 바이너리로서 '괜찮게' 실행되는 것 같습니다... 하지만 그것은 여기서 다룰 내용이 아닙니다. 이것은 '현대적인' 빌드이기에, 별다른 복잡한 작업이 필요하지 않았습니다. 그냥 잘 작동했습니다. 놀랍게도 말이죠. 물론 몇 년 뒤의 사람들에게는 이 말이 사실이 아니겠지만요.

Binutils

특별히 볼 것이나 말할 것이 많지는 않습니다. 그저 binutils 2.46.0을 사용했고, 별도의 설정 없이 바로 구성 및 빌드되었습니다. 좋네요.

../binutils-2.46.0/configure --target=ia64-linux-gnu --prefix=/usr/local/ia64-linux-gnu

GCC

이 부분은 약간 이상합니다. Itanium은 사양(dying) 플랫폼이 아니라, 이미 완전히 죽은(dead) 플랫폼이기 때문입니다. 비록 단 한 명의 사용자, René Rebe가 불꽃을 계속 살려두고 있기는 하지만, 저는 언급된 버전인 15가 여전히 작동하는지 확인하기 위해 이 버전을 사용하기로 했습니다. 스포일러를 하자면, 작동했습니다!

macOS에서 빌드한다는 것은 Homebrew가 설치되어 있다는 뜻이기도 하며, 덕분에 수많은 의존성 (dependencies)을 일일이 수동으로 빌드하는 대신 GCC를 위한 의존성들을 간단히 brew로 설치할 수 있었습니다. 그 덕분에 설정 (configuring) 과정이 조금 더 복잡해지긴 했습니다.

../gcc-15.3.0/configure \
--target=ia64-linux-gnu \
--prefix=/usr/local/ia64-linux-gnu \
...

zlib 때문에 빌드를 방해하는 fdopen의 이상한 중복 정의 (duplicate define)가 있습니다. 정말 황당하네요.

In file included from ../../gcc-15.3.0/zlib/zutil.c:10:
In file included from ../../gcc-15.3.0/zlib/gzguts.h:21:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:61:
...

해결 방법은 당연히 zutil.h의 140번 라인을 주석 처리하는 것입니다.

그 후에는 대부분 빌드될 것입니다. (binutils 바이너리가 경로 (path)에 있는지 확인하세요!)

export PATH=/usr/local/ia64-linux-gnu/bin:$PATH

모든 Linux 관련 항목을 빌드하려고 하기 때문에 pthread가 없다고 불평하겠지만, 우리는 상관하지 않습니다.

In file included from ../../../gcc-15.3.0/libgcc/gthr.h:157,
from ../../../gcc-15.3.0/libgcc/libgcov-interface.c:27:
./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory
...

하지만 libgcc.a는 수동으로 복사해야 했습니다.

cp ia64-linux-gnu/libgcc/libgcc.a /usr/local/ia64-linux-gnu/ia64-linux-gnu/lib/libgcc.a'.

그런 다음 그냥 gcc 디렉토리로 이동하여 make install을 실행하면 됩니다.

이로써 펌웨어를 빌드하기 위한 Itanium 크로스 컴파일러 (cross compiler)를 갖게 되었습니다!

jsteve@Jasons-Mac-mini gcc % /usr/local/ia64-linux-gnu/bin/ia64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/ia64-linux-gnu/bin/ia64-linux-gnu-gcc
...

멋지네요!

Qemu

과거에 의존성들을 Homebrew로 설치한 적은 분명히 있지만, 정확히 무엇이었는지는 도무지 기억나지 않네요.

먼저 소스 (source)를 가져옵니다 (현재 시점인 2026년 7월 31일 기준).

git clone --branch merced --single-branch https://github.com/makuhlmann/qemu-system-ia64.git

그 다음 빌드 디렉토리 (build directory)를 만듭니다. 소스 디렉토리 내에서 직접 빌드하지는 않으니까요!

macOS에서 설정 (Configuring)하는 것은 물론이고.... 기묘합니다.

../qemu-system-ia64/configure \
--disable-qom-cast-debug \
--disable-stack-protector \
...

저는 macOS를 사용 중이기 때문에 coca 백엔드 (backend)를 사용하고 싶었고, 그래서 GTK+나 SDL은 신경 쓰지 않았습니다.

그다음부터는 그저 make를 실행하는 문제뿐이었습니다... 6개의 코어를 사용하기 위해 -j6를 사용했더니 소스 코드를 빠르게 훑고 지나갔고, 몇 분 후 이상한 오류와 함께 멈췄습니다. 저는 그냥 다시 'make'를 입력했고 완료되었습니다.... 무엇 때문에 멈췄는지는 확실하지 않지만, 정말 상관없습니다.

이번 설치를 위해 저는 이 이미지를 사용합니다:

MD5 체크섬 (checksum)은 다음과 같습니다: 604ee3141ed6a34391a89a33c0019702

XP Itanium 버전은 매우 많지만, 잘못된 버전을 구하기가 너무 쉽습니다.

설치 (Installing)

이제 '어려운' 부분입니다. 이것을 실제로 설치하는 것이죠.

먼저 하드 디스크를 생성합니다. 예를 들어 20GB 정도로 말이죠?

./merced-build/qemu-img create -f vmdk ia64-xp64-merced.vmdk 20G
Formatting 'ia64-xp64-merced.vmdk', fmt=vmdk size=21474836480 compat6=off hwversion=undefined

이것은 Roy Tam 덕분에 제가 사용하는 방식입니다!

merced-build/qemu-system-ia64-unsigned \
-bios ./merced-build/roms/ia64-firmware/ia64-firmware.bin \
-machine ia64-vpc,i8042=off,nvram=ia64fw-nvram-merced.bin \
...

그렇게 하면 EFI 펌웨어 (firmware)로 부팅됩니다.

펌웨어 이미지로 환영받는 것은, 우리가 우리의 GCC 크로스 컴파일러 (cross compiler)로 Itanium 펌웨어를 정말로 크로스 컴파일 (cross compile) 할 수 있다는 사실을 다시 한번 확인시켜 줍니다!

그러면 CD-ROM에서 CD로 부팅하려면 아무 키나 누르라는 메시지가 뜹니다.

이 시점에서 Qemu가 고해상도 모니터에서 스케일링 (scale)이 잘 되지 않는다는 점을 언급해야겠습니다. 하지만 zoom-to-fit 옵션을 활성화했기 때문에, 창 크기를 조절하여 읽을 수 있거나 그냥 최대화할 수 있습니다.

여기서부터는 기본적으로 일반적인 XP 설치 과정입니다.

과거의 RISC와 달리, 시스템 파티션 (partition)의 생성은 이제 다른 모든 EFI/UEFI 플랫폼과 마찬가지로 설치 프로그램에 의해 처리됩니다.

이 점은 정말 좋은 변화라고 말하고 싶네요.

거기서 남은 디스크 공간을 선택하기만 하면 됩니다. 저는 NTFS (quick)로 포맷하며, 그러면 파일 복사가 시작됩니다. 저의 경우 5분 이내에 완료되었습니다.

빠르게 재부팅하면 이제 그래픽 설치 프로그램 (graphical installer)에 진입하게 됩니다.

여기서 시스템이 충돌하거나 완전히 멈출(lock hard) 수 있습니다. 그런 경우에는 하드 디스크 이미지 (hard disk image)를 다시 생성하고 설치를 다시 시도하세요. 저는 5번의 시도 끝에 성공했습니다. 다만 syunn의 포크 (fork)를 사용했을 때는 단 한 번도 설치를 완료할 수 없었다는 점을 언급해야겠네요.

질문이 나오면 저는 그냥 기본 네트워크 설정을 선택했습니다.

이전 빌드들에서는 여러 순간에 실패하거나 시스템이 완전히 멈추곤 했으며, 전체 성공률은 5번 중 1번꼴이었습니다. 최상은 아니었죠. 하지만 오늘 XP 2600을 딱 한 번 설치했는데, 30~40분 만에 1:1 성공률로 완료되었습니다. 그러니 언제나 그렇듯 상황은 계속 변하고 있으며, 훨씬 좋아지고 있다고 말할 수 있겠네요!

제 m4에서는 약 30분이 더 걸렸고, 그러고 나면 완료됩니다.

자, 이렇게 됐습니다!

RDP를 설정하고 원격 데스크톱 애플리케이션을 사용하는 것을 강력히 추천합니다. 현재 화살표 키가 너무 자주 반복 입력되어 타이핑이 고역이기 때문입니다. 또한, 이는 coca 비디오 스케일링 (video scaling) 문제도 해결해 줄 것입니다.

미래는?

그렇다면 Windows XP 2003 버전은 어떨까요?

즉: 5.2.3790.0.srv03_rtm.030324-2048_ia64fre_client-professional_retail_en-us-NRMPIFPP_EN.iso

동일한 설정에 다른 ISO를 사용했는데, 네, 제 m4 Mac Mini에서 약 40분 만에 설치되었습니다.

심지어 사용 가능한 가장 초기 Windows Server Itanium 빌드인 5.1.2462도 설치되고 실행됩니다! 물론 2001년 8월 이전 버전을 설치하세요.

다른 운영 체제는 어떨까요?

현재로서는 다른 어떤 것도 작동하지 않는 것 같습니다. Monterey도, HPUX, VMS 등도 별다른 성과가 없었습니다.

여기서 어디로 가야 할까요? 컴파일러 (Compilers)! 그리고 기타 등등 말이죠. 말할 필요도 없이, 이것은 1세대 Itanium이기 때문에 제가 Itanium을 가지고 있었을 때 빌드했던 모든 것들은 Itanium2 기반이었으므로 실행되지 않을 것입니다. 깨진 바이너리 호환성 (binary compatibility)이 정말 매력적이지 않나요?

이것이 바로 80386이 1987년만큼이나 2026년에도 여전히 유효한 이유입니다.

물론, Apple은 단지 그럴 수 있다는 이유만으로 그것을 망가뜨릴 것입니다.