Một trong những nhà phát triển của Google đã trình bày trên danh sách gửi thư LLVM chủ đề phát triển một thư viện C tiêu chuẩn đa nền tảng (Libc) trong khuôn khổ dự án LLVM.
Vì nhiều lý do, Google không hài lòng với libc hiện tại (glibc, musl) và công ty đang đi đúng hướng để phát triển một triển khai mới, mà anh ấy dự định phát triển như một phần của LLVM. Sự phát triển của LLVM gần đây đã được sử dụng làm cơ sở để xây dựng các công cụ của Google.
Việc phát triển được lên kế hoạch từ từ, tăng dần chức năng. Người ta đề xuất rằng các tùy chọn đầu tiên có dạng một lớp trung gian giữa ứng dụng và hệ thống libc, từ đó các tính năng chưa được thực hiện sẽ được mượn.
Sau khi đạt đến một mức chức năng nhất định, Libc mới có thể được sử dụng thay thế hoàn toàn cho hệ thống Libc.
Nó được lên kế hoạch để bắt đầu với sự hỗ trợ cho kiến trúc x86-64, Linux và ràng buộc tĩnh (tải động, đóng gói và các kiến trúc bổ sung sẽ được triển khai lần thứ hai).
Dự án vẫn đang trong giai đoạn phát triển ban đầu, nhưng các mục tiêu cơ bản đã được xác định:
- Mô-đun hóa và phát triển phù hợp với triết lý cung cấp một thư viện chi tiết, chứ không phải là một quần thể nguyên khối.
- Hỗ trợ liên kết tĩnh trong các chế độ PIE (thực thi độc lập vị trí) và không có PIE. Cung cấp CRT (C Runtime) và bộ tải PIE cho các tệp thực thi được liên kết tĩnh.
- Hỗ trợ hầu hết các chức năng của thư viện C tiêu chuẩn với các trình cắm thêm POSIX và một số tiện ích mở rộng dành riêng cho hệ thống được yêu cầu trong các ứng dụng hiện có.
- Thái độ cẩn thận đối với các tiện ích mở rộng cụ thể từ nhà cung cấp và chỉ thêm chúng khi cần thiết. Đối với hỗ trợ mở rộng của bên thứ ba, đề xuất sử dụng phương pháp tiếp cận dự án Clang và libc ++.
- Sử dụng các phương pháp hay nhất trong phát triển bằng các công cụ LLVM, chẳng hạn như việc áp dụng các chất khử trùng và loại bỏ các xét nghiệm ngay từ đầu.
Một trong những nhà phát triển LLVM tích cực đã chỉ ra rằng phân phối libc như một phần của bộ công cụ LLVM nó không phải là không có ý nghĩa, nhưng nhìn chung với nhu cầu như vậy họ sử dụng thư viện musl, Nó được viết tốt, hỗ trợ nhiều kiến trúc và cung cấp các chức năng cần thiết, bao gồm cả liên kết động.
Việc kết hợp Musl vào LLVM và sự phát triển của nó như một ngã ba đồng bộ với dự án chính có thể được chứng minh.
Ý kiến của ông cũng được bày tỏ bởi tác giả của dự án Musl, người đã cố gắng tranh luận tại sao đề xuất của Google và việc đưa Libc vào phân phối LLVM là những ý tưởng rất tồi:
Phát triển và duy trì libc chính xác, tương thích và chất lượng cao là một nhiệm vụ rất khó khăn. Vấn đề không nằm ở số lượng mã, mà ở việc cung cấp hành vi chính xác.
Và những khó khăn với việc triển khai giao diện, xem xét kho lưu trữ khổng lồ các ứng dụng được viết bằng C / C ++, cũng như các ứng dụng bằng các ngôn ngữ khác mà thời gian chạy được sử dụng bởi Libc.
Cách tiếp cận trán mà không tính đến các sắc thái sẽ chỉ dẫn đến thực tế là nhiều chương trình hiện tại sẽ không thể hoạt động với Libc, nhưng một dự án như vậy sẽ không được người tiêu dùng quan tâm.
Sự phát triển của công ty có thể hủy hoại Libc, nhưng thúc đẩy việc sử dụng rộng rãi, dẫn đến việc cần thêm các bản hack để đảm bảo tính tương thích trong các ứng dụng.
Sự phát triển dưới sự bảo trợ của một dự án công ty mở sẽ thúc đẩy phạm vi bao phủ đối với các nhu cầu và quyết định của công ty, làm phương hại đến lợi ích của cộng đồng.
Ví dụ, trong trường hợp xác định sự cố do lỗi trong một chương trình khác của chính bạn, trong quá trình phát triển được kiểm soát, việc đảm bảo tính tương thích của Libc với lỗi này sẽ dễ dàng hơn là tự sửa lỗi.
Apple sử dụng BSD libc fork cho những mục đích này và Google sử dụng Fuchsia fork. Kinh nghiệm của nhà phát triển Musl cho thấy rằng các luật sư đã liên hệ với anh ta chủ yếu để làm rõ các vấn đề cấp phép.
Fuente: http://lists.llvm.org