Tại sao trình biên dịch thường chỉ tạo các tệp thực thi cho nền tảng mà chúng được cài đặt trên?

Tôi là nhà phát triển C ++ và trong nỗ lực hiểu rõ hơn về phát triển đa nền tảng, tôi đang cố gắng hiểu rõ hơn về một số chi tiết triển khai của trình biên dịch và cách chính xác họ tạo ra các nhị phân cụ thể của hệ điều hành. Giữa nghiên cứu của tôi, tôi nhận ra rằng, ít nhất trong một thời gian, hầu hết các trình biên dịch bạn đã tải xuống cho một nền tảng cụ thể chỉ biên dịch nhị phân cho nền tảng đó. Vì vậy, nếu bạn đã tải xuống một IDE đi kèm với trình biên dịch exe cho Windows, thì trình biên dịch đó sẽ chỉ có thể biên dịch chương trình của bạn cho các ứng dụng windows x86-x64 chứ không phải các ứng dụng Linux hoặc Mac.

Bây giờ tôi hiểu rằng các nền tảng khác nhau đòi hỏi các định dạng nhị phân khác nhau, nhưng điều gì gây khó khăn khi nói trình biên dịch C ++ trực quan trên windows để tạo tệp thực thi nhị phân linux? Miễn là bạn có các hướng dẫn lắp ráp cho CPU mà bạn đang chạy, cũng như các thư viện cụ thể của hệ điều hành, bạn không nên biên dịch các ngoại lệ cho bất kỳ nền tảng nào trên bất kỳ máy nào?

Điều gì gây khó khăn khi nói trình biên dịch C ++ trực quan trên windows để tạo tệp thực thi nhị phân linux?

Khác với việc không sẵn lòng làm điều đó về phía Microsoft, hoàn toàn không có gì. Những trở ngại không phải là kỹ thuật.

Các công cụ phát triển chỉ là các chương trình lấy đầu vào và sản xuất đầu ra. Visual C ++ tạo ra x86 assembly và sau đó sử dụng một trình biên dịch để chuyển đổi nó thành tệp đối tượng COFF. Nếu Microsoft muốn làm cho nó tạo ELF thay vào đó, thì đó chỉ là mã: lắp ráp, ELF sẽ ra mắt. Không có gì kỳ diệu về các tệp đối tượng hoặc thư viện; chúng chỉ là những đốm dữ liệu ở định dạng được hiểu rõ.

Quay trở lại thời kỳ đồ đá, việc biên dịch chéo khó khăn hơn rất nhiều vì thường thì bạn sẽ viết chuỗi công cụ cho nền tảng mục tiêu của mình để lắp ráp cho nền tảng nơi nó sẽ chạy. Điều này có nghĩa là nếu tất cả những gì có trên thế giới là các kiến ​​trúc VAX, M68K và Alpha, thì một bộ trình biên dịch chéo đầy đủ sẽ yêu cầu viết chín trong số chúng, chủ yếu là từ đầu. (VAX-to-VAX, VAX-to-M68K, VAX-to-Alpha, M68K-to-VAX, M68K-to-M68K, v.v.) Đó là một chút cường điệu vì các phần của trình biên dịch VAX có thể được sử dụng lại và được gắn vào các trình tạo mã cho từng mục tiêu (ví dụ: VAX, M68K và Alpha, mỗi mục được viết cho VAX.)

Vấn đề đó đã biến mất khi chúng tôi bắt đầu viết trình biên dịch bằng ngôn ngữ không gắn với bộ xử lý cụ thể, chẳng hạn như C. Đi theo tuyến đó có nghĩa là bạn viết toàn bộ chuỗi công cụ một lần bằng C và sử dụng nền tảng được viết cho nền tảng cục bộ Trình biên dịch C để xây dựng nó. (Bạn thường sử dụng trình biên dịch để tự biên dịch lại sau khi nó đã được bootstraged trên trình biên dịch của nền tảng cục bộ, nhưng đó là một cuộc thảo luận khác.) Kết quả của việc này là xây dựng trình biên dịch chéo về cơ bản giống như việc xây dựng trình biên dịch gốc nền tảng địa phương. Sự khác biệt đáng kể duy nhất là ở đâu đó trong quá trình xây dựng, bạn đã bảo nó biên dịch trong trình tạo mã cho nền tảng đích của bạn thay vì nền tảng cho nền tảng cục bộ, đó sẽ là lựa chọn hợp lý.

Khi kiến ​​trúc của trình biên dịch phát triển, nó trở nên thuận tiện khi chỉ cần bao gồm và xây dựng tất cả các trình tạo mã với sản phẩm và chọn cái nào được sử dụng trong thời gian chạy. Clang / LLVM làm điều này và tôi chắc chắn có những người khác.

Khi bạn có một toolchain hoạt động (trình biên dịch, trình biên dịch, trình liên kết), các thư viện sẽ được xây dựng từ các nguồn và cuối cùng bạn kết thúc với mọi thứ bạn cần để tạo một tệp thực thi cho một số nền tảng khác.

Có, nếu bạn có tất cả thông tin về nền tảng mục tiêu của mình thì việc bạn thực sự chạy trên nền tảng nào không thành vấn đề.

Có hai vấn đề có xu hướng tăng lên:

1. Mọi người không tập trung vào nó bởi vì đó là một kịch bản ít phổ biến hơn. Thường thì điều duy nhất bạn biên dịch chéo là trình biên dịch để sau đó bạn có thể dừng biên dịch chéo. Ít tập trung có nghĩa là hỗ trợ tồi tệ hơn.
2. Các chương trình không tầm thường cần nhiều hơn là chỉ mã. Xử lý việc bao gồm / liên kết thư viện trở nên dễ dàng hơn một chút khi bạn có thư viện cho nền tảng mà bạn đang chạy. Họ sẽ ở một địa điểm nổi tiếng, trong một mã hóa nổi tiếng.

Tất nhiên những điều đó không thể vượt qua. Hầu hết, bạn có được trình biên dịch nhắm mục tiêu nền tảng mà họ chạy trên đó là những gì mọi người muốn.

Tôi không đồng ý với tiền đề của bạn. Có hàng triệu nhà phát triển Android và iOS. Và tất cả họ đều sử dụng trình biên dịch chạy trên Windows hoặc Mac, tạo mã cho một máy tính hoàn toàn khác.

Bạn sẽ không nhận được trình biên dịch chéo nếu không có nhu cầu thị trường cho nó. Ví dụ, những người phát triển mã cho máy tính để bàn Linux hầu hết đều có sẵn máy tính để bàn Linux và sẽ sử dụng trình biên dịch dựa trên Linux - nhanh hơn nhiều nếu bạn có thể chạy ứng dụng của mình trực tiếp trên máy nơi nó được biên dịch mà không cần vận chuyển qua mạng, dễ dàng và nhanh hơn nhiều để có một trình sửa lỗi chạy trên cùng một máy và cứ thế.

Vậy Microsoft sẽ kiếm thêm bao nhiêu tiền nếu trình biên dịch của họ cũng sẽ xây dựng cho Linux? Khoảng $ 0. Bao nhiêu phần mềm cho Windows sẽ được tạo ra? Không ai. Bao nhiêu phần mềm Linux sẽ được tạo ra? Không có ý tưởng, nhưng đó không phải là điều mà Microsoft quan tâm. Chi phí sẽ là bao nhiêu? Khá đáng kể. Trình biên dịch phải không có lỗi. Họ phải được kiểm tra.

Một vấn đề khác: Nếu bạn viết một trình biên dịch viết trên Windows, bạn cần một người biết cách viết phần mềm Windows. Nếu bạn viết một trình biên dịch cho Linux, bạn cần một người biết cách viết phần mềm Linux. Nếu bạn viết một trình biên dịch cho Linux chạy trên Windows, đột nhiên bạn cần một loại bánh mì hiếm hơn của nhà phát triển biết cả Windows và Linux.