GCC
[image]
'''G'''NU '''C'''ompiler '''C'''ollection
공식 사이트
GNU 프로젝트의 오픈 소스 컴파일러 컬렉션. 유닉스/리눅스 계열 플랫폼의 사실상 표준 컴파일러다. 리처드 스톨먼이 1987년에 만들었다.
처음에는 C 컴파일러였으며 'GNU C Compiler'의 약어였다. 하지만 기능이 추가되면서 C++ 같은 다른 언어도 지원하게 되었고[1], 'GNU Compiler Collection'으로 이름을 변경하였다. 물론 약어는 여전히 GCC이다. 공식적으로 지원하는 언어는 C, C++, Objective-C, Fortran, Ada, Go이다. Java는 GCC 7.1 버전부터 지원이 중단되었다. GNU 진영에서는 GCC로 컴파일을 하고 Make를 이용해 빌드하는 것이 일반적이다.
원래는 C로 구현되었으나 2013년에 구현 언어를 C++로 모두 변경하였다. # 만들어진지 수십년 된 컴파일러라 최적화는 매우 잘 되어 있지만, 기존 코드의 구조가 시대적 한계로 인해 오늘날 관점에서는 상당히 더러워서 신규 인력이 거의 유입되지 않았기 때문이다.
MinGW(Minimalist GNU for Windows)라는 윈도우용 포크도 존재하여 여러 오픈 소스 프로그램들을 윈도우에서 돌아가게 하는 데 일조하고 있다.
MinGW는 MSYS와의 결합으로 구동된다. MSYS는 Minimal SYStem의 약자로, 윈도우에서 유닉스의 터미널 환경을 제공해 주며 이를 통해 MinGW와 GCC를 설치하는 것이다. MSYS와 비슷한 형태를 가진 Cygwin은 단순 터미널이 아닌 일종의 가상머신으로, 윈도우 위에 POSIX 레이어를 새로 얹어 상당히 무거운 반면 MinGW는 POSIX 호환성을 포기한 대신 윈도우 환경과 네이티브로 연결되기 때문에 더 빠른 성능을 제공한다. 이런 이유로 유닉스에서 POSIX API를 이용하는 소스 코드를 작성했을 경우 MinGW로는 컴파일이 불가능하다. Windows 10 Anniversary Update에서는 WSL(Windows Subsystem for Linux)이라는 이름으로 리눅스 API가 윈도우 커널 내부에 직접 탑재되었으므로, 윈도우에서 POSIX 환경을 이용하고 싶다면 WSL을 이용하면 된다.
기존의 MSYS 1.0은 32비트 운영체제만 지원한다는 문제점이 있었는데, 이에 따라 MSYS2 기반의 MinGW-w64가 제작되어 64비트 윈도우 환경을 지원하게 되었다. 참고로 윈도우 환경에서의 GCC는 기존의 유닉스, 리눅스용 GCC와 동일하게 작동하지 않는 경우가 있다. 와이드바이트 관련 예약어나 함수(wchar_t, wprintf(), wcstok() 등)가 대표적인 예.
윈도우 파일 입출력 시 파일을 제대로 읽지 못하는 등의 문제가 있고, 비주얼 스튜디오에서만 쓰이는 비표준 확장 함수도 제공하고 있기 때문에 C/C++ 입문자에게는 권장할 만한 것이 못 된다는 의견이 있으나, 이는 MS Windows의 로케일 문제에서 비롯된다. Windows의 경우 Windows 10 RS5에 표준 로케일을 UTF-8로 사용하는 옵션[2]이 베타로 추가되어 있으나 이 옵션은 기본값이 아니기에 전역 시스템 로케일은 별도로 설정된 로케일을 따르게 된다. Windows에서 유니코드 Aware한 프로그램을 작성하는 경우 기본적으로 wchar_t 와 같은 와이드바이트 형식 (Windows 에서는 UTF-16)을 사용하게 되며, 기본적으로는 시스템의 MBCS를 따르게 되어 일반적인 방법으로는 파일에 접근하는 방법이 전무하다. C의 fopen()의 프로토타입은 const char* 형식만 존재하고 이는 MBCS를 따르기 때문에 로케일에서 벗어나는 파일명은 접근할 수 없다. MSVC의 경우 비표준 함수인 const wchar_t 오버라이드를 제공하고 있으나, 표준이 아닌 관계로 libc를 사용하는 GCC의 경우 이러한 파일에 접근할 수 있는 방법이 CreateFileW()와 같은 OS 자체의 API를 사용하는 것 이외에는 방법이 존재하지 않는다. 또한 콘솔의 wprintf() 또한 콘솔의 기본값은 역시나 시스템 로케일을 따르며 이 또한 로케일을 벗어나는 문자열의 정상적인 출력을 위해서는 WriteConsoleW()를 사용하여야 하는 등, Windows가 사용하는 MBCS의 문제점이지 MSYS 환경의 문제점이 아니다.
Cygwin의 기능은 WSL로 확실히 대체되었지만, MinGW는 윈도우 환경을 그대로 유지하되 리눅스 명령어만 사용해야 할 경우[3] 유용하게 쓰일 수 있어 여전히 필요성이 있는 소프트웨어이다.
2017년 말 기준, LLVM/Clang과의 성능 비교에서 우위를 차지하는 것으로 나타났다. # 최근에는 Clang과 경쟁적으로 새로운 기능을 더하고 버전 번호도 높이고 있다. 코드를 분석해 문제가 될만한 부분을 진단해주는 기능 등이 크게 강화되었다.
임베디드 프로그래밍을 할 때도 크로스 컴파일을 GCC로 하는 경우가 많다.
2007년에 출시된 4.2.2 버전부터 라이선스가 GPLv3로 바뀌었고, 이에 따라 BSD 라이선스와 호환이 불가능하게 되어 FreeBSD 진영과 애플은 대경실색하고 LLVM/Clang으로 갈아탔다.[9]
'''G'''NU '''C'''ompiler '''C'''ollection
공식 사이트
1. 개요
GNU 프로젝트의 오픈 소스 컴파일러 컬렉션. 유닉스/리눅스 계열 플랫폼의 사실상 표준 컴파일러다. 리처드 스톨먼이 1987년에 만들었다.
처음에는 C 컴파일러였으며 'GNU C Compiler'의 약어였다. 하지만 기능이 추가되면서 C++ 같은 다른 언어도 지원하게 되었고[1], 'GNU Compiler Collection'으로 이름을 변경하였다. 물론 약어는 여전히 GCC이다. 공식적으로 지원하는 언어는 C, C++, Objective-C, Fortran, Ada, Go이다. Java는 GCC 7.1 버전부터 지원이 중단되었다. GNU 진영에서는 GCC로 컴파일을 하고 Make를 이용해 빌드하는 것이 일반적이다.
원래는 C로 구현되었으나 2013년에 구현 언어를 C++로 모두 변경하였다. # 만들어진지 수십년 된 컴파일러라 최적화는 매우 잘 되어 있지만, 기존 코드의 구조가 시대적 한계로 인해 오늘날 관점에서는 상당히 더러워서 신규 인력이 거의 유입되지 않았기 때문이다.
2. MinGW
MinGW(Minimalist GNU for Windows)라는 윈도우용 포크도 존재하여 여러 오픈 소스 프로그램들을 윈도우에서 돌아가게 하는 데 일조하고 있다.
MinGW는 MSYS와의 결합으로 구동된다. MSYS는 Minimal SYStem의 약자로, 윈도우에서 유닉스의 터미널 환경을 제공해 주며 이를 통해 MinGW와 GCC를 설치하는 것이다. MSYS와 비슷한 형태를 가진 Cygwin은 단순 터미널이 아닌 일종의 가상머신으로, 윈도우 위에 POSIX 레이어를 새로 얹어 상당히 무거운 반면 MinGW는 POSIX 호환성을 포기한 대신 윈도우 환경과 네이티브로 연결되기 때문에 더 빠른 성능을 제공한다. 이런 이유로 유닉스에서 POSIX API를 이용하는 소스 코드를 작성했을 경우 MinGW로는 컴파일이 불가능하다. Windows 10 Anniversary Update에서는 WSL(Windows Subsystem for Linux)이라는 이름으로 리눅스 API가 윈도우 커널 내부에 직접 탑재되었으므로, 윈도우에서 POSIX 환경을 이용하고 싶다면 WSL을 이용하면 된다.
기존의 MSYS 1.0은 32비트 운영체제만 지원한다는 문제점이 있었는데, 이에 따라 MSYS2 기반의 MinGW-w64가 제작되어 64비트 윈도우 환경을 지원하게 되었다. 참고로 윈도우 환경에서의 GCC는 기존의 유닉스, 리눅스용 GCC와 동일하게 작동하지 않는 경우가 있다. 와이드바이트 관련 예약어나 함수(wchar_t, wprintf(), wcstok() 등)가 대표적인 예.
윈도우 파일 입출력 시 파일을 제대로 읽지 못하는 등의 문제가 있고, 비주얼 스튜디오에서만 쓰이는 비표준 확장 함수도 제공하고 있기 때문에 C/C++ 입문자에게는 권장할 만한 것이 못 된다는 의견이 있으나, 이는 MS Windows의 로케일 문제에서 비롯된다. Windows의 경우 Windows 10 RS5에 표준 로케일을 UTF-8로 사용하는 옵션[2]이 베타로 추가되어 있으나 이 옵션은 기본값이 아니기에 전역 시스템 로케일은 별도로 설정된 로케일을 따르게 된다. Windows에서 유니코드 Aware한 프로그램을 작성하는 경우 기본적으로 wchar_t 와 같은 와이드바이트 형식 (Windows 에서는 UTF-16)을 사용하게 되며, 기본적으로는 시스템의 MBCS를 따르게 되어 일반적인 방법으로는 파일에 접근하는 방법이 전무하다. C의 fopen()의 프로토타입은 const char* 형식만 존재하고 이는 MBCS를 따르기 때문에 로케일에서 벗어나는 파일명은 접근할 수 없다. MSVC의 경우 비표준 함수인 const wchar_t 오버라이드를 제공하고 있으나, 표준이 아닌 관계로 libc를 사용하는 GCC의 경우 이러한 파일에 접근할 수 있는 방법이 CreateFileW()와 같은 OS 자체의 API를 사용하는 것 이외에는 방법이 존재하지 않는다. 또한 콘솔의 wprintf() 또한 콘솔의 기본값은 역시나 시스템 로케일을 따르며 이 또한 로케일을 벗어나는 문자열의 정상적인 출력을 위해서는 WriteConsoleW()를 사용하여야 하는 등, Windows가 사용하는 MBCS의 문제점이지 MSYS 환경의 문제점이 아니다.
Cygwin의 기능은 WSL로 확실히 대체되었지만, MinGW는 윈도우 환경을 그대로 유지하되 리눅스 명령어만 사용해야 할 경우[3] 유용하게 쓰일 수 있어 여전히 필요성이 있는 소프트웨어이다.
3. 설치
- MSYS2: GCC 설치 과정 #[8]
- MSYS2(x86_64) 다운로드 후 MSYS2 셸에 pacman -Syu[4]를 입력하여 패키지 데이터베이스와 코어 시스템 업데이트[5]
- 셸에 pacman -S mingw-w64-x86_64-toolchain을 입력
- 셸에 pacman -S mingw-w64-x86_64-cmake mingw-w64-x86_64-extra-cmake-modules를 입력하여 CMake 설치
- 환경변수 Path에 ~/mingw64/bin[6] 경로 추가
- 윈도우 명령 프롬프트 창에서 gcc -v, g++ -v, mingw32-make -v[7], cmake -version, gdb -v를 각각 입력하여 정상 설치 여부 확인
- MSYS2: GPGME error: Invalid crypto engine 에러 발생 시 #
- 셸 종료 후 (MSYS2 폴더)/var/cache/pacman/pkg 경로에서 libgpgme, gnupg, pacman 패키지 파일(.pkg.tar) 삭제
- (MSYS2 폴더)/etc 경로에서 텍스트 에디터로 pacman.conf 파일을 열고 SigLevel = Never의 주석 기호(#) 제거, SigLevel = Required DatabaseOptional 주석 처리
- MSYS2 셸에 pacman -S libgpgme gnupg pacman 입력
- 기타 필요한 파일 모두 재설치
- MSYS 1.0: Couldn't reserve space for cygwin's heap 에러 발생 시 #
- 이곳에서 rebase.exe 파일을 클릭하여 다운로드(다운로드 시 파일명을 bin-rebase.exe에서 rebase.exe로 변경)
- rebase.exe 파일을 (MSYS 폴더)/MinGW/msys/1.0/bin 경로로 이동
- bin 폴더에서 명령 프롬프트 창을 열고 rebase -b 0x30000000 msys-1.0.dll 입력
- TDM-GCC: MSYS 등이 서브시스템에 상당수 의존하는 것과 달리 순수 Windows 환경에서 사용을 목적으로 한 MinGW. 한 패키지로 i686, AMD64 바이너리 생성이 가능하다.
- MSYS 없이 바로 사용이 가능해서 가벼운 편이지만 셸 스크립트를 돌릴 방법이 없으므로 autotools와 같은 구식의 configurator와 사용하기는 어렵다. Visual Studio Code처럼 자체적인 빌드 환경이 없는 텍스트 에디터로 컴파일을 하고자 할 때 가장 권장된다. 2020년 3월, 무려 5년만에 새 업데이트가 등록되었다.
4. 기타
2017년 말 기준, LLVM/Clang과의 성능 비교에서 우위를 차지하는 것으로 나타났다. # 최근에는 Clang과 경쟁적으로 새로운 기능을 더하고 버전 번호도 높이고 있다. 코드를 분석해 문제가 될만한 부분을 진단해주는 기능 등이 크게 강화되었다.
임베디드 프로그래밍을 할 때도 크로스 컴파일을 GCC로 하는 경우가 많다.
2007년에 출시된 4.2.2 버전부터 라이선스가 GPLv3로 바뀌었고, 이에 따라 BSD 라이선스와 호환이 불가능하게 되어 FreeBSD 진영과 애플은 대경실색하고 LLVM/Clang으로 갈아탔다.[9]
[1] C++용 GCC는 gcc-c++ 혹은 g++라고 한다.[2] Beta: 세계 언어 지원을 위해 Unicode UTF-8 사용[3] 주로 오픈 소스 라이브러리를 빌드할 때.[4] 아치 리눅스의 패키지 관리자 명령어이다.[5] 마지막에 'error: target not found: update'라는 에러 메시지가 뜨지만 이건 업데이트가 모두 끝났다는 의미로 받아들이면 된다.[6] 에디터에서 컴파일러 툴체인 세팅을 요구할 경우 이 경로를 입력해 주면 된다.[7] 구 32비트 MinGW에 포함된 make는 유닉스 시스템의 명령어를 그대로 사용하는 반면, MinGW-w64에 포함된 make는 기존의 것을 네이티브 윈도우 환경에 맞춰 약간 변형한 것이기 때문에 이름이 mingw32-make로 바뀌었다.[8] MSYS2 폴더의 maintenancetool.exe 파일을 실행하면 MSYS2를 삭제할 수 있다.[9] 심지어 애플은 터미널에 gcc 명령어를 입력하면 clang으로 연결되도록 바꿔버리기까지 했다.(...) 최신 macOS에서 'gcc -v'를 입력하여 나오는 출력 결과는 Apple LLVM과 clang의 버전이다.