맞지만, 실제로는 호환되지 않아서 골치 아픔. 기초 시스템 프로그래밍 수업을 가르치는데, GCC 전용 코드나 명령을 주면 매년 macOS를 쓰는 학생들이 이상한 오류에 시달림.
Homebrew 등으로 진짜 GCC를 설치하고 나서도 gcc가 실제 GCC를 실행하도록 PATH 설정까지 배워야 함. 잘못된 libc에 링크되는 문제도 있었던 것으로 기억함. Windows 사용자는 WSL만 설치하면 되니 오히려 사정이 나음.
macOS의 gcc 바이너리는 사실상 거짓말쟁이임. 거짓말하는 사람도 나쁘지만, 거짓말하는 프로그램도 나쁘다고 봄.
맞음. 오래된 Makefile 중에는 컴파일러가 GCC뿐이라고 가정하고 gcc를 직접 호출하는 것이 많음. GCC가 설치되어 있다고 가정하는 C 프로그래밍 튜토리얼을 따라 하는 경우도 있음.
이런 트램펄린 바이너리는 의외로 흔한 패턴임. Nix와 Rustup도 비슷한 방식을 사용함.
개발 도구 디렉터리를 그냥 PATH에 추가하지 않는 이유는, 환경 변수로 경로를 쉽게 바꿀 수 있게 하려는 것 아닐까 싶음. DEVELOPER_DIR=/my/path/to/Xcode.app/Contents/Developer로 설정하면 clang을 실행할 때 해당 Xcode의 Clang과 SDK를 사용하게 됨.
그래도 그냥 PATH 를 썼다면 훨씬 이해하기 쉬웠을 거라는 데는 전적으로 동의함.
Nix와 Rustup도 비슷한 방식을 쓴다는 부분이 궁금한데, 좀 더 자세히 설명해 줄 수 있을까?
설정에 따라 개발 도구 경로가 여러 곳일 수 있음. Xcode가 /Applications에 없을 수도 있고, /Library/Developer/CommandLineTools에 설치되는 Command Line Tools 패키지를 쓸 수도 있으며, 여러 Xcode 버전을 오가며 사용할 수도 있음.
사용자는 xcode-select 로 Xcode 버전을 바꾸면 셸의 PATH를 수정하지 않아도 도구가 즉시 선택한 버전으로 전환되기를 기대함. Apple의 도구 모음 선택 방식을 고려하면, 처음에는 이상해 보여도 나름 타당한 접근임.
현재 환경이 궁금하다면 xcode-select -print-path로 xcrun 기반 도구가 참조하는 루트 경로를 확인할 수 있음.
본문이나 댓글에서 아직 못 본 내용이라 덧붙이자면, macOS가 GCC와 다른 개발 도구를 감싸는 방식에는 Xcode 라이선스 동의를 반복해서 확인하는 성가신 동작이 있음.
한 번만 확인하는 게 아니라 종종 다시 요구함. 어떤 업데이트 뒤인지, 라이선스가 바뀔 때인지는 모르겠지만 여러 차례 동의해야 했음.