Tại sao glibc được duy trì tách biệt với GCC?


13

GCC là trình biên dịch C. Glibc là thư viện C. Tuy nhiên, đó có phải là một điều cần thiết tuyệt đối cho trình biên dịch và thư viện chuẩn được gói cùng với nhau khi triển khai C không?

Ví dụ, các thư viện C chứa ABI và trình biên dịch cụ thể những thứ như thế <limits.h>, <stdint.h>vv, mà khác nhau giữa các trình biên dịch và các API. Và các chi tiết như "cách gọi một hàm chính" cũng phụ thuộc vào trình biên dịch, nhưng thực tế những chi tiết đó được cung cấp bởi libc.sotrên một hệ thống Linux. Ví dụ: nếu tôi thay đổi trình biên dịch để hoạt động với ABI khác, như sử dụng intvới 8 byte, thư viện C sẽ không còn hoạt động nữa vì những thứ trong đó <limits.h>sẽ trở nên sai.

Câu trả lời:


20

Một trong những lý do là GCC có thể được xây dựng và sử dụng trên các hệ thống Unix độc quyền như MacOSX, Solaris, HPUX hoặc một số FreeBSD) có thư viện chuẩn C của riêng họ .

Ngay cả trên Linux, bạn có thể có một thư viện chuẩn C không phải là GNU Glibc . Cụ thể, bạn có thể xây dựng GCC (hoặc sử dụng nó) trên các hệ thống Linux bằng musl-libc hoặc với Bionic (hệ thống Android) hoặc với dietlibc , v.v. Và một hệ thống Linux có thể có GNU Glibc và sử dụng một số trình biên dịch C khác (như Clang hoặc TinyCC).

Ngoài ra, thư viện C phụ thuộc rất nhiều vào nhân Linux. Một số phiên bản cũ của kernel có thể yêu cầu một số loại (hoặc phiên bản) cụ thể củalibc

Và GCC có thể xây dựng như một trình biên dịch chéo .

Và các chi tiết như "cách gọi mainhàm" cũng phụ thuộc vào trình biên dịch, nhưng trên thực tế, những chi tiết đó được cung cấp bởi libc.sotrên một hệ thống Linux.

Điều đó không chính xác. Các mainhàm được gọi (trong một môi trường lưu trữ) bởi crt0 thứ, một số trong đó được cung cấp bởi GCC (ví dụ /usr/lib/gcc/x86_64-linux-gnu/6/crtbegin.otrên tôi Debian / Sid / x86-64 là từ libgcc-6-devgói). Đọc thêm vềlibgcc

Trên thực tế, có một số mối quan hệ nửa ẩn giữa libcvà GCC, ví dụ: vì nhiều libctiêu đề (tùy chọn) sử dụng một số nội dung gcc hoặc thuộc tính hàm .

(do đó, các nhà phát triển GCC và nhà phát triển libc GNU phải tương tác)

.... nếu tôi thay đổi trình biên dịch để hoạt động với ABI khác ...

Bạn sẽ cần ... /configuretrình biên dịch GCC và xây dựng lại nó, và thậm chí bạn có thể cần phải trình biên dịch GCC (để mô tả ABI của bạn và gọi các quy ước ). Các x32 ABI là một ví dụ điển hình.

Cuối cùng, một số người đóng góp cho hoặc người duy trì GCC (bao gồm cả tôi) đã ký một chuyển nhượng bản quyền bao gồm GCC nhưng không phải là GNUglibc .

(liên quan đến giấy phép GCC, đọc kỹ ngoại lệ thư viện thời gian chạy GCC )

Lưu ý rằng một số tiêu đề tiêu chuẩn, như <limits.h>hoặc <stdint.h>được cung cấp bởi GCC; một số khác, giống như <stdlib.h>được "sửa" trong quá trình xây dựng GCC: quy trình xây dựng trình biên dịch sẽ đưa chúng từ triển khai Libc và vá chúng. Tuy nhiên, các tiêu đề tiêu chuẩn khác (có thể <stdio.h>và các tiêu đề nội bộ mà nó bao gồm) được lấy từ libc. Đọc thêm về GCC FIXINCLUDES và các tệp tiêu đề cố định .

(điều cố định là điều tôi (Basile) vẫn chưa hiểu rõ)

Bạn có thể biên dịch gcc -v -Hđể hiểu chính xác hơn chương trình thực tế nào đang chạy (vì gcclà trình điều khiển, chạy cc1trình biên dịch, trình liên kết ld& trình biên dịch, trình biên dịch , v.v.) và các tiêu đề được bao gồm, thư viện và tệp đối tượng nào được liên kết (thậm chí ngầm, bao gồm thư viện chuẩn C và crt0 ). Tìm hiểu thêm về các tùy chọn GCCcollect2as .

BTW, bạn có thể sử dụng thư viện chuẩn C khác với thư viện mà GCC của bạn mong đợi hoặc được xây dựng cho (ví dụ musl-libchoặc một số chế độ ăn kiêng ), bỏ qua các đối số bổ sung thích hợp để gcc...


1
Câu trả lời đúng, ngay cả khi không phải là một thiết kế chính xác. Đây là lý do tại sao MSVC ++ có thể biên dịch mã C ++ 11 / C ++ 14 cho Hệ điều hành trước 2011/2014, nhưng GCC thường không thể.
MSalters

Bạn có ý nghĩa gì bởi "không phải là một thiết kế chính xác"? Và tôi không chắc chắn rằng GCC không thể biên dịch mã C ++ 14 cho các HĐH cũ (tuy nhiên, bạn có thể cần phải biên dịch GCC gần đây trên HĐH cũ đó).
Basile Starynkevitch

Theo ISO C, Thư viện chuẩn C là một phần của trình biên dịch. Điều tương tự giữ cho thư viện C ++. Bây giờ vấn đề là các ứng dụng được xây dựng với phiên bản GCC mới sẽ có sự phụ thuộc vào glibc của HĐH nơi chúng được xây dựng, có thể mới hơn glibc trên hệ thống đích. Một giải pháp tốt hơn có lẽ đã dựa vào một giải pháp dựa trên gcclibccác thư viện HĐH, nhưng được phiên bản như một phần của GCC chứ không phải HĐH.
MSalters

Bạn có chắc chắn rằng các tiêu chuẩn C11 hoặc C ++ 14 đề cập đến từ "trình biên dịch" không? AFAIU họ nói về "triển khai" (thậm chí có thể không phải là một phần mềm)
Basile Starynkevitch

1
Một số tiêu đề, như <stdint.h>hoặc <limits.h>thực sự được cung cấp bởi GCC. Các tiêu đề khác, như <stdlib.h>được lấy từ thư viện C và "cố định" trong quá trình xây dựng GCC.
Basile Starynkevitch

-5

Câu trả lời ngắn gọn là nếu cả hai được 'kết hợp' với nhau, glibc sẽ được cấp phép theo GPL *, và do đó nó sẽ hoàn toàn không phù hợp với các dự án độc quyền. Mặc dù dự án FSF và GNU không yêu thích phần mềm độc quyền, glibc đã được cấp phép LGPL như một lựa chọn chiến lược để thúc đẩy áp dụng GCC và hệ sinh thái phần mềm miễn phí. GCC thực sự được cấp phép theo GPL với một ngoại lệ liên kết thời gian chạy cụ thể, vì tình hình có phần lầy lội. glibc được cấp phép theo LGPL để cho phép các tình huống thư viện chia sẻ hợp lý.

https://www.gnu.org/licenses/gcc-exception-faq.html

Ngoài ra, glibc có tất cả các loại miếng chêm và các thành phần khác để điều chỉnh nó cho các hệ điều hành khác nhau và việc phân phối cùng một gói với gcc cũng sẽ khiến mọi thứ trở nên lộn xộn.

* Thay vào đó, GCC có thể được cấp phép theo một GPL khác, mặc dù suy nghĩ của FSF về điều đó sẽ đi theo hướng "trên cơ thể đã chết của tôi".


3
Xin lỗi, nhưng câu trả lời này là IMHO sai. "Ghép lại với nhau" không ngụ ý glibc nuôi dưỡng một "tác phẩm xuất phát" từ GCC theo nghĩa được mô tả trong GPL. Ví dụ, hàng tấn gói phần mềm sử dụng các giấy phép nguồn mở khác nhau được "gói cùng nhau" trong mỗi bản phân phối Linux, tuy nhiên các gói này không vi phạm GPL.
Doc Brown

Tại sao việc kết hợp gcc và glibc lại với nhau buộc glibc phải ở dưới GPL? Tôi hiểu rằng các gói không phải là một "công việc kết hợp", vì vậy GPL không vượt qua ranh giới. Chỉnh sửa: những gì Doc Brown nói :-)
Philip Kendall
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.