컴파일러가 일반적으로 설치된 플랫폼의 실행 파일 만 생성하는 이유는 무엇입니까?

저는 C ++ 개발자이며 크로스 플랫폼 개발을 더 잘 이해하기 위해 컴파일러의 일부 구현 세부 사항과 OS 별 바이너리를 정확히 만드는 방법을 더 잘 이해하려고합니다. 내 연구 중에 적어도 한동안 특정 플랫폼에 대해 다운로드 한 대부분의 컴파일러가 해당 플랫폼에 대해 컴파일 된 바이너리 만 있다는 것을 깨달았습니다. 따라서 Windows 용 컴파일러 exe와 함께 제공된 IDE를 다운로드하면 해당 컴파일러는 Linux 또는 Mac 응용 프로그램이 아닌 x86-x64 Windows 응용 프로그램에 대해서만 프로그램을 컴파일 할 수 있습니다.

이제 플랫폼마다 다른 이진 형식이 필요하다는 것을 알고 있지만 Windows의 Visual C ++ 컴파일러가 Linux 이진 실행 파일을 생성하는 것이 어려워지는 이유는 무엇입니까? 실행중인 CPU 및 OS 특정 라이브러리에 대한 어셈블리 지침이있는 한 어떤 시스템의 플랫폼에 대해서도 실행 파일을 컴파일 할 수 없어야합니까?

Windows에서 Visual C ++ 컴파일러가 Linux 바이너리 실행 파일을 생성하기 어려운 이유는 무엇입니까?

마이크로 소프트 측에서는 그렇게하지 않으려는 것 외에는 전혀 아무것도 없다. 장애물은 기술적이지 않습니다.

개발 툴체인은 입력을 받고 출력을 생성하는 프로그램입니다. Visual C ++는 x86 어셈블리를 생성 한 다음 어셈블러를 사용하여 COFF 개체 파일로 변환합니다. Microsoft가 대신 ELF를 생성하게하려면 코드 일뿐입니다. 어셈블리가 들어오고 ELF가 나옵니다. 객체 파일이나 라이브러리에 대한 마술은 없습니다. 잘 이해 된 형식의 데이터 덩어리 일뿐입니다.

석기 시대로 거슬러 올라가면 크로스 컴파일은 훨씬 더 어려웠습니다. 왜냐하면 타겟 플랫폼의 툴 체인을 실행하는 플랫폼에 대한 어셈블리로 작성했을 것입니다. 즉, 세상에 VAX, M68K 및 Alpha 아키텍처 만 있으면 크로스 컴파일러 전체를 9 개씩 작성해야합니다. (VAX-to-VAX, VAX-to-M68K, VAX-to-Alpha, M68K-to-VAX, M68K-M68K 등) VAX 컴파일러의 일부를 재사용 할 수 있기 때문에 약간 과장된 것입니다. 각 대상의 코드 생성기에 연결 (예 : VAX, M68K 및 Alpha, 각각 VAX 용으로 작성)

C와 같은 특정 프로세서와 연결되지 않은 언어로 컴파일러를 작성하기 시작했을 때 그 문제는 사라졌습니다. 경로를 따라 가면 전체 툴체인을 C로 한 번 작성하고 로컬 플랫폼을 위해 작성했습니다 그것을 빌드하는 C 컴파일러. (종종 로컬 플랫폼의 컴파일러에서 부트 스트랩 된 후에 컴파일러를 사용하여 자체 재 컴파일하는 경우가 많지만, 또 다른 논의입니다.) 이것의 결과는 크로스 컴파일러를 빌드하는 것이 본질적으로 네이티브 컴파일러를 빌드하는 것과 같은 노력이되었다는 것입니다. 로컬 플랫폼. 유일한 차이점은 빌드 프로세스의 어딘가에서 로컬 플랫폼 용 코드 생성기 대신 대상 플랫폼 용 코드 생성기에서 컴파일하도록 지시 한 것입니다. 논리적 선택이었습니다.

컴파일러의 아키텍처가 발전함에 따라 제품에 모든 코드 생성기를 포함 및 빌드하고 런타임에 사용할 코드 생성기를 선택하는 것이 편리해졌습니다. Clang / LLVM 이이 작업을 수행하며 다른 것도 있습니다.

일단 작동하는 툴체인 (컴파일러, 어셈블러, 링커)이 있으면 라이브러리는 소스에서 빌드되고 결국 다른 플랫폼 용 실행 파일을 생성하는 데 필요한 모든 것을 얻게됩니다.

예, 대상 플랫폼에 대한 모든 정보가 있다면 실제로 실행중인 플랫폼과 상관 없습니다.

자라는 경향이있는 두 가지 문제가 있습니다.

1. 덜 일반적인 시나리오이기 때문에 사람들은 그것에 집중하지 않습니다. 종종 크로스 컴파일하는 것은 컴파일러이므로 크로스 컴파일을 중지 할 수 있습니다. 초점이 적을수록 지원이 더 나빠집니다.
2. 사소한 프로그램은 단순한 코드 이상의 것을 필요로합니다. 실행중인 플랫폼에 대한 라이브러리가 있으면 라이브러리 포함 / 연결을 다루기가 약간 쉬워집니다. 잘 알려진 인코딩 위치에서 잘 알려진 위치에있게됩니다.

그것들은 물론 극복 할 수 없습니다. 대부분의 경우 사람들이 원하는 플랫폼을 대상으로하는 컴파일러를 사용하게됩니다.

나는 당신의 전제에 동의하지 않습니다. 수백만 명의 Android 및 iOS 개발자가 있습니다. 그리고 그들은 모두 Windows 또는 Mac에서 실행되는 컴파일러를 사용하여 완전히 다른 컴퓨터의 코드를 생성합니다.

시장 수요가 없다면 크로스 컴파일러를 얻지 못할 것입니다. 예를 들어 Linux 데스크톱 용 코드를 개발하는 사람들은 대부분 Linux 데스크톱을 사용할 수 있으며 Linux 기반 컴파일러를 사용합니다. 네트워크를 통해 코드를 전송하지 않고 컴파일 된 시스템에서 응용 프로그램을 직접 실행할 수있는 경우 훨씬 빠릅니다. 디버거가 같은 머신에서 실행되도록합니다.

그렇다면 컴파일러가 Linux 용으로 구축한다면 Microsoft가 얼마나 더 많은 돈을 벌 수 있을까요? 약 $ 0. 더 많은 Windows 용 소프트웨어를 만들 수 있습니까? 없음 더 많은 리눅스 소프트웨어가 만들어 질까요? 잘 모르겠지만 Microsoft가 관심을 갖는 것은 아닙니다. 비용은 얼마입니까? 꽤 많이 요 컴파일러에는 버그가 없어야합니다. 테스트를 받아야합니다.

또 다른 문제 : Windows에서 작성하는 컴파일러를 작성하는 경우 Windows 소프트웨어 작성 방법을 알고있는 사람이 필요합니다. Linux 용 컴파일러를 작성하는 경우 Linux 소프트웨어 작성 방법을 알고있는 사람이 필요합니다. Windows에서 실행되는 Linux 용 컴파일러를 작성하는 경우 갑자기 Windows와 Linux를 모두 알고있는 훨씬 더 드문 개발자가 필요합니다.