2008-10-09 3 views
36

저는 C++ 개발자는 아니지만 항상 컴파일러에 관심이 있었고 일부 GCC 항목 (특히 LLVM)에 관심을 가졌습니다.GCC-Windows가 cygwin에 의존하는 이유는 무엇입니까?

Windows에서 GCC는 제대로 실행하려면 POSIX 에뮬레이션 계층 (cygwin 또는 MinGW)이 필요합니다.

왜 그럴까요?

저는 C++로 작성되고 다른 플랫폼 (Subversion, Firefox, Apache, MySQL) 용으로 크로스 컴파일 된 많은 소프트웨어를 사용하며 cygwin 또는 MinGW가 필요하지 않습니다.

C++ 베스트 프랙티스 프로그래밍에 대한 제 생각은 합리적으로 플랫폼 중립적 인 코드를 작성하고 컴파일 프로세스 중 모든 차이점을 처리 할 수 ​​있다는 것입니다.

그래서 GCC는 무엇입니까? Windows에서 기본적으로 실행할 수없는 이유는 무엇입니까?


편집 :

좋아, 두 개의 응답 지금까지 기본적으로 "는 POSIX의 헤더를 사용하기 때문에 GCC는 POSIX 층을 사용한다"라고.

하지만 그 질문에는 실제로 대답하지 않습니다.

이미 내가 좋아하는 표준 라이브러리에 대한 헤더 집합이 있다고 가정 해 보겠습니다. 왜 여전히 posix 헤더가 필요한가요?

GCC는 실제로 cygwin/mingw를 필요로합니까 RUN?

아니면 헤더와 라이브러리 에뮬레이션 레이어 만 있으면됩니까? 그렇다면 왜 필자는 필요한 리소스가있는 "lib"디렉토리를 제공하지 못합니까? 다시


편집 :

좋아, 나는 또한 the D Programming Language에서 코드를 작성 ... 질문을 명확히하기 위해 다시

을 시도 할 것이다. 공식적인 컴파일러의 이름은 "dmd"이고 Windows와 Linux 모두를위한 공식적인 컴파일러 바이너리가 있습니다.

Windows 버전에는 POSIX 에뮬레이션이 필요하지 않습니다. 그리고 리눅스 버전은 Win32 에뮬레이션을 필요로하지 않습니다. 컴파일러가 환경에 대한 가정을 가지고 있다면, 가정을 꽤 잘 숨긴다.

물론 표준 라이브러리를 찾을 위치와 정적으로 또는 동적으로 링크 할 라이브러리를 어디에서 찾을 지 컴파일러에게 알려야합니다. 대조적으로, GCC는 posix 환경에서 작동하는 것으로 주장하며 ME에게 에뮬레이션 레이어를 설정하여 이러한 가정을 유머러스하게 묻습니다.

하지만 정확히 GCC에서 그 레이어를 사용하고 있습니까? 그냥 stdlib 헤더를 찾고 있는가? "/ usr/lib"내의 헤더를 찾는다 고 가정한다.

그렇다면 헤더 파일을 찾기 위해 "C :/gcc/lib"를 살펴 보라고 말하면 안됩니까?

또는 GCC 자체가 POSIX 라이브러리를 사용하여 파일 시스템에 액세스하고 다른 저수준 항목을 수행합니까? 그렇다면 왜 그들이 그들이 좋아하는 윈도우 POSIX 라이브러리와 정적으로 링크하지 않는지 궁금하다. 사용자가 종속성을 설정할 때 응용 프로그램에 종속성을 설정할 수 있어야하는 이유는 무엇입니까?

+0

지금부터 몇 가지 * 올바른 * 대답을 선택하십시오. MinGW에는 cygwin1.dll이 필요하지 않습니다. 핵심 gcc 팀이 Microsoft Windows를 지원하지 않는다는 사실을 알고 싶다면이를 묻는 것이 좋습니다. –

+0

리눅스에서 Visual Studio 및 VC++를 실행하려면 왜 WINE 또는 다른 것이 필요합니까? –

답변

2

다른 플랫폼 용으로 컴파일 된 대부분의 소프트웨어가 MinGW에서 컴파일됩니다. gcc와의 유일한 차이점은 컴파일러 자체 인입니다. 즉, 일반적으로 프로그램에서 컴파일되는 모든 헤더가 필요하며 일반적으로 결과 프로그램을 실행할 필요가없는 헤더가 필요합니다.

+1

이 답변은 다소 혼란 스럽습니다. –

3

Windows는 표준 POSIX 라이브러리를 제공하지 않으므로 cygwin에서 표준 POSIX 라이브러리 (cygwin1.dll)를 제공합니다. cygwin과 함께 제공되는 gcc 패키지는 그것을 사용합니다.

mingw는 POSIX 계층을 반드시 제공하지 않습니다. 예를 들어 내가 사용하는 설치는 pthread 라이브러리조차 가지고 있지 않습니다.

필요하면 설치해야합니다. Mingw-gcc는 Win32 네이티브 코드를 생성합니다 (사실 MSVCRT.DLL을 사용합니다).

편집 : GCC 자체와 Mingw/Cygwin에서 라이브러리를 필요로하거나 승리에 GCC로 컴파일 된 프로그램이

+0

제 질문은 다음과 같이 바꿔 쓸 수 있습니다 : 왜 GCC의 사용자로서, 내 컴퓨터에 POSIX 에뮬레이션 레이어를 먼저 설치해야합니까? – benjismith

+1

@benjismith : 아니면 왜 Visual Studio 사용자로서 Linux 컴퓨터에 Windows 에뮬레이션 레이어를 먼저 설치해야합니까? 두 가지 질문은 나와 같은 양의 감각을 만드는 것처럼 보입니다. –

+0

@David, Visual Studio 용 소스 코드가 없으므로 바이너리에 필요한 것을 제공해야합니다. 소스 코드 Gcc가 있으므로 에뮬레이션 계층을 요구하지 않고도 빌드 할 수 있어야합니다. 나는 MinGW가하는 일을 가정한다. –

37

사실 이러한 라이브러리를 필요로하는 경우, 질문의 전제는 이유를 묻는다면 나는 더 이상 확신 당신의 편집을 읽는 wrong : MinGW GCC는 이 아니며은 Cygwin이 필요합니다.

Cygwin이 전혀 필요하지 않음을 알 수 있습니다. Windows (32 비트, 적어도)에서 기본적으로 실행됩니다. 툴 체인과 생성 된 바이너리는 모두 Cygwin과 독립적입니다.

Cygwin에서 사용할 수있는 MinGW 컴파일러는 다릅니다 : Cygwin 런타임에 종속되지 않는 코드를 생성하기 위해 Cygwin 플랫폼에서 빌드됩니다. 이 경우 컴파일러 자체는 Cygwin에 의존합니다. Cygwin에서 설치했기 때문입니다.

5

나는 Windows에서 내 프로그램이 좋은 Windows 시민처럼 행동하고, Linux에서 좋은 Linux 시민처럼 행동하려고 노력한다.

+5

항상 그렇듯이, 월터, 당신은 그 사람입니다! 두 플랫폼에서 매우 사용하기 쉬운 컴파일러를 만들어 주셔서 감사합니다! 참고 :이 주석을 읽은 다른 사람들의 경우 월터 (Walter)는 D 프로그래밍 언어 용 "dmd"컴파일러 작성자입니다 (원래 게시물에서 크로스 플랫폼 코딩의 훌륭한 예제로 언급 했음). – benjismith

+0

MingW는 주로이 목표를 달성합니다. –

+0

@ 브래드,하지만 핵심 GCC 개발자의 도움없이. – RBerteig

29

GCC의 Cygwin 버전은 Cygwin가 컴파일 프로그램, 설치해야합니다.

MinGW 버전은 Windows 작업용 이외의 다른 컴파일 작업이 필요하지 않습니다.

Cygwin 환경은 미리 컴파일 된 라이브러리의 경로를 변경하기 때문에 Cygwin 환경과 MinGW 컴파일러를 함께 사용할 수 없습니다.

bash 스타일의 쉘이 필요하지만 Cygwin을 사용하지 않으려면 MSYS을 권장합니다.는 MinGW

달리

Cygwin에서이 MinGW Wiki에서 복사
그것에서 POSIX 기능에 대한 Cygwin® POSIX 에뮬레이션 DLL 또는 cygwin1.dll에 의존하기 때문에 원칙적으로 Cygwin에서 응용 프로그램은 "기본 Win32 응용 프로그램"으로 간주되지 않으며, win32 함수를 직접 사용하지 않습니다. MinGW는 Win32 API에서 제공하는 함수를 제공합니다. MinGW에서 응용 프로그램을 이식하는 동안 응용 프로그램을 제대로 작동 시키려면 fork(), mmap() 또는 ioctl()과 같은 Win32 고유의 함수를 Win32에 상응하는 함수로 다시 구현해야합니다.

7

POSIX (휴대용 운영 체제 인터페이스) "IEEE에 의해 생산 및 ANSI와 ISO에서 표준화되고있는 진화, 성장 문서입니다. POSIX의 목표는 응용 프로그램의 소스 코드 이식성이다"[1].

실질적으로 목표는 하나의 소스 구현을 작성하고 재 컴파일만으로 다른 (POSIX 호환) 시스템에서 실행되도록하는 기능입니다.

GCC는 그 약속을 제공 할 수있는 컴파일러이므로 기계에 "최대"POSIX 표준을 가져 오는 코드 계층이 필요합니다.

귀하의 질문에 대한 답변의 핵심입니다.

  • 는 사용자로부터 입력으로 일부 디렉토리 경로를 취하고을 stdout에 씁니다 OS 별 위해서 #ifdefs로하는 프로그램을 작성 :

    것은 무슨 뜻인지 볼 수 있도록, 당신이 운동을 제공합니다 그것의 내용 (1 수준)의 명부 작성.

나는 당신이

그것은있을 수 약간 덜 어려운 그 사용하는 코드를 작성하는 것입니다 유닉스 또는 리눅스 시스템에서 컴파일에만 기본 WIN32 API를 사용하여 코드를 작성하는 것은 매우 어렵다는 것을 발견 할 것이다 생각 POSIX API - 모든 LINUX 상자에서 할 수있는 것처럼 - 그리고 Windows에서 컴파일해야합니다. (DevStudio2005에는 놀라 울 정도로 많은 POSIX 호환 헤더가 있습니다. 가까운 장래에 얻을 수 있습니다.)

위에서 Linux 프로그램을 가져 와서 Cygwin 또는 MinGW에서 실행되는 GCC에서 컴파일하십시오. 나는 그것을 컴파일하고 실행 내기 것입니다.

GCC는 어떻게 그 마법을 수행 했습니까? POSIX 헤더와 그것들을 구현 한 구현체는 Cygwin이나 MinGW에서 제공했다.

Windows에서 Cygwin/MinGW에 대한 GCC의 의존도가 더 좋습니까?

  1. POSIX.4 : 실제 세계, 빌 O. Gallmeister, 주식 오라일리 & 동료, 프로그래밍, 페이지 2
4

이유는 무엇입니까? 왜냐하면 GCC을 만들었을 때 Windows 32 비트가 종료되지 않았기 때문입니다 ...

더 정확하게하려면 --- UNIX/Posix OS 용으로 개발되었습니다. 나중에 그것은 창문에 이식되었습니다.

Windows는 POSIX 컴퍼넌트 시스템이 아닙니다.그것은 심지어 아주 기본적인 기능을 제공하지 않습니다. Windows 컴파일러에서 readdir 또는 stat을 찾으십니까? 그리고 이것은 컴파일러를 작성하는 데 필요한 extreamly 기본 기능입니다!

GCC 컴파일 프로그램은 일반적으로 실행하기 위해 누락 된 기능을 추가하기 위해 mingw32.dll 하나만 필요했습니다.

그래서 ... 왜 GCC에 POSIX 레이어가 필요한지 묻습니다. Windows OS는 POSIX 운영 체제가 아니기 때문에.

+1

거의 완전히 잘못되었습니다. Windows는 (최소) POSIX 호환이며 준수 인증을 받았습니다. 'readdir'와'stat'는 컴파일러가 사용할 가능성이 적은 함수들입니다. –

+0

@Ben Voigt - Windows (최소) POSIX 호환성은 농담입니다. 그것 ** ** 최소성 **는 그것을 완전히 무용하게 만들고 소프트웨어를 이식하는 것을 돕지 않는다. C 또는 C++ 컴파일러를위한 파일 시스템의 운영은 매우 중요하고 중요합니다. – Artyom

+0

@Artoym : 진실은, 유닉스 계열 OS의 광범위한 스펙트럼에서 컴파일되지만 POSIX API뿐만 아니라 SUS (Single Unix Specification) API가 필요하기 때문에 Win32가 아닌 이유입니다. 그리고 컴파일러에 필요한 유일한 파일 시스템 작업은 파일 열기, 읽기, 쓰기, 닫기, 그리고 아마도 POSIX의 일부이며 Windows에서 완벽하게 지원됩니다. 디렉토리 목록이 필요없고, 파일 타임 스탬프를 확인할 필요가 없다 (쉘은 globbing을 처리한다.'make' 유틸리티는 변경된 의존성을 검사한다. 이것들은 컴파일러의 일부가 아니다). –

3

은 내가 C++ 개발자 모르겠지만, 을했습니다 항상 컴파일러에 관심이, 가 나는 으로 GCC 물건 (특히 LLVM)

의 일부를 땜질에 관심이 있어요

LLVM과 GCC는 관련이 없습니다. LLVM은 주로 Chris Lattner (http://llvm.org/developers.cgi)가 현대적인 최적화에 대해 수행 한 연구의 결과입니다. 그의 논문은 http://llvm.org에 있습니다. 요즘, 그것은 애플에 의해 크게 후원됩니다. GCC의 C/C++/Obj-C 프론트 엔드는 LLVM 머신 코드를내는 llvm-gcc에 사용됩니다 (그리고 llvm에서 많은 양의 최적화가 끝나면 최종 실행 파일이 나옵니다). llvm-gcc는 준비된 C/C++/Obj-C 프론트 엔드를 LLVM에 연결하는 해킹의 일종입니다.

어쨌든 LLVM 팀원도 clang이라고하는 완전한 C/C++/Obj-C 컴파일러를 빌드한다는 것에 유의하십시오. 그것은 C 구현이 거의 완료되었고, C++ 지원은 Obj-C에 대해 더 좋아지고 더 좋아지고 있습니다.

누군가 "컴파일러 llvm"이라고 말하면, 그는 정말로 llvm-gcc 또는 clang을 의미합니다. LLVM 자체는 저수준 가상 머신이며 Static Single Assignment 형식 (약 32 명령어, 아 페어)의 명령어가 몇 개 밖에 없지만 최적화의 메가톤은 구문 트리에 전달됩니다.

-3

GCC의 사람들은 열정으로 Windows를 싫어하기 때문에 (언젠가 스톨 먼을 읽으십시오). 따라서 GCC를 Windows로 포팅 할 때 그들은 단지 다른 유닉스 인 것처럼 가장하기 위해 최선을 다합니다.

그건 아마도 POSIX 종속성을 코드에서 제거하는 데 시간을 낭비하고 싶지 않을 것입니다.

+3

증오를 가정하고, GCC 뒤에있는 많은 사람들이 GNU 사람들이 아니라고 생각하십시오. 명시 적으로 유닉스 중심의 두 회사는 구글과 오라클이다. 증오를 가정하기보다는 GCC *가 유닉스 플랫폼 용 컴파일러라고 생각하십시오. MinGW는 전 세계의 비 유닉스 플랫폼 중 일부에 불과한 포트입니다. * 오히려 그 증거를 증명하는 데 자신의 증거를 가져 오십시오. * –

+1

그리고 필자가 아는 대부분의 오픈 소스 및 자유 소프트웨어 사용자는 창을 싫어하지 않습니다 (가장 큰 것! = 다수). 우리는 그것에 대해 아무런 감정이 없습니다. –

+0

음, 가장 시끄러운 것들이 지금까지 운동의 목소리로 허용되었습니다. RMS의 경우 독점 소프트웨어 (Windows 포함)에 대한 비방을 많이 찾을 필요가 없습니다. 예를 들면 다음과 같습니다. http://www.fsf.org/blogs/rms/can-we- rescue-olpc-from-windows –

0

pthreads 또는 OpenMP를 지원하지 않으려는 경우 gcc를 빌드 할 때 posix 이외의 enable-threads 옵션을 지정하는 옵션이 있습니다. 말할 것도없이, 그것들은 잘 테스트되지 않았습니다. Windows 스레드가있는 OpenMP에 대한 제 3 자 폐쇄 소스 지원이 있지만 gcc와 함께 사용하면 라이센스를 위반 한 것으로 보입니다. Windows pthreads 라이브러리는 Windows 스레드 기능에 대한 상위 수준의 인터페이스이기 때문에 성능이 좋지 않거나 Microsoft가 선호도 지원을 거부 한 경우 놀라운 일이 아닙니다. 최근에는 Microsoft가 Windows에서 gcc를 허용하기 시작했습니다. gcc 사용자가보고 한 버그에 대해서는 Microsoft 도구만으로 복제 할 수 있다고해도 실제로는 작동하지 않는다고 말한 적이있었습니다.