Wikipedia

Khác biệt giữa bản sửa đổi của “GNU C Library”

Thư viện chuẩn ngôn ngữ lập trình C thuộc dự án GNU
Thay đổi sau →
Nội dung được xóa Nội dung được thêm vào
Trực quanMã wiki
Tạo với bản dịch của trang “GNU C Library”
(Không có sự khác biệt)

Phiên bản lúc 15:39, ngày 5 tháng 9 năm 2020

GNU C Library, thường được gọi là glibc, là phần triển khai thư viện chuẩn C của Dự án GNU. Bất chấp cái tên của nó, nó hiện cũng hỗ trợ trực tiếp C++ (và gián tiếp, các ngôn ngữ lập trình khác). Nó được bắt đầu vào đầu những năm 1990 bởi Free Software Foundation (FSF) cho hệ điều hành GNU của họ.

GNU C Library
Thiết kế bởiRoland McGrath
Phát triển bởiGNU Project
Phát hành lần đầu1987; 37 năm trước (1987)[1]
Kho mã nguồn
Viết bằngC
Hệ điều hànhUnix-like
Thể loạiRuntime library
Giấy phépLGPLv2.1[2]
Websitewww.gnu.org/software/libc/
Linux API được cấu thành từ System Call Interface của nhân Linux, GNU C Library (của GNU), libdrm, libalsa và libevdev (củafreedesktop.org).
GNU C Library là một trình bao bọc xung quanh các lời gọi hệ thống của nhân Linux kernel.
Linux kernel và GNU C Library cùng nhau tạo thành Linux API. Sau khi biên dịch, các mã nhị phân cung cấp một ABI.

Phát hành theo GNU Lesser General Public License, glibc là phần mềm tự do nguồn mở. Dự án GNU C Library cung cấp các thư viện cốt lõi cho các hệ thống GNU và GNU/Linux, cũng như nhiều hệ thống khác sử dụng Linux làm kernel. Các thư viện này cung cấp các API quan trọng bao gồm ISO C11, POSIX.1-2008, BSD, dành riêng cho hệ điều hành và hơn thế nữa. Các API này bao gồm các cơ sở nền tảng như open, read, write, malloc, printf, getaddrinfo, dlopen, pthread_create, crypt, login, exit...

Lịch sử

Dự án glibc ban đầu được viết chủ yếu bởi Roland McGrath, làm việc cho Free Software Foundation (FSF) trong những năm 1980 khi còn thiếu niên.[3]

Tháng 2 năm 1988, FSF mô tả glibcgần như đã hoàn thành chức năng theo yêu cầu của ANSI C.[4] Đến năm 1992, nó đã triển khai các chức năng ANSI C-1989 và POSIX.1-1990 và công việc đang được tiến hành trên POSIX.2.[5]

Tháng 9 năm 1995 Ulrich Drepper đã có đóng góp đầu tiên của mình cho dự án glibc và trong những năm 1990 đã dần trở thành người đóng góp và duy trì cốt lõi của glibc. Drepper giữ vị trí bảo trì trong nhiều năm và cho đến năm 2012 đã tích lũy được 63% tổng số cam kết cho dự án.[6]

Linux libc

Đầu những năm 1990, các nhà phát triển nhân Linux đã phân nhánh glibc. Fork của họ, "Linux libc", được duy trì riêng biệt.

Khi FSF phát hành glibc 2.0 vào tháng 1 năm 1997, các nhà phát triển hạt nhân đã ngừng Linux libc do sự tuân thủ vượt trội của glibc 2.0 với chuẩn POSIX.[7] glibc 2.0 cũng có khả năng quốc tế hóa tốt hơn và dịch chuyên sâu hơn, khả năng IPv6, truy cập dữ liệu 64-bit, tiện ích cho các ứng dụng đa luồng, khả năng tương thích với phiên bản trong tương lai và mã cơ động hơn.[8]

Phiên bản Linux libc được sử dụng cuối cùng đã sử dụng tên nội bộ (soname) libc.so.5. Tiếp theo từ điều này, glibc 2.x trên Linux sử dụng soname libc.so.6[9] (kiến trúc Alpha và IA64 bây giờ dùng libc.so.6.1, thay thế). Tên file *.so thường được viết tắt là libc6 (ví dụ trong tên gói trong Debian) theo quy ước thông thường cho các thư viện.

Theo Richard Stallman, FSF không thể hợp nhất những thay đổi được thực hiện trong Linux libc thành glibc do quyền tác giả mơ hồ. Dự án GNU khá nghiêm ngặt về bản quyền và tác quyền.[10]

Thành lập ban chỉ đạo

Bắt đầu từ năm 2001, sự phát triển của thư viện đã được giám sát bởi một ủy ban,[11] với Ulrich Drepper[12] giữ vai trò là người đóng góp và bảo trì chính. Việc thành lập ban chỉ đạo bị bao vây bởi một cuộc tranh cãi công khai vì nó được Ulrich Drepper mô tả công khai là một việc tiếp quản thù địch thất bại của Richard Stallman.[13][14]

Chuyển sang Git, một phân phối VCS

Trong khi trước đó lưu trong kho CVS, năm 2009 glibc đã chuyển sang Git (một hệ thống kiểm soát phiên bản phân tán) trên Sourceware.

Debian chuyển sang EGLIBC và quay lại

Sau những tranh cãi kéo dài xung quanh phong cách lãnh đạo của Drepper và sự chấp nhận đóng góp từ bên ngoài,[15][16] Debian đã công khai chuyển sang glibc fork EGLIBC năm 2009,[17] và quay trở lại với Debian 8.0 (Jessie) tháng 4 năm 2015.

Giải tán Ban chỉ đạo

tháng 3 năm 2012, ban chỉ đạo đã bỏ phiếu để tự giải tán và loại bỏ Drepper để ủng hộ quy trình phát triển dựa vào cộng đồng, với Ryan Arnold, Maxim Kuvyrkov, Joseph Myers, Carlos O'Donell, và Alexandre Oliva giữ trách nhiệm bảo trì GNU (nhưng không có thêm quyền ra quyết định).[18][19]

Sau sự thay đổi về bảo trì glibc, Debian và các dự án khác vốn đã chuyển sang các giải pháp thay thế đã quay lại với glibc.[20] Từ đầu năm 2014, the glibc fork EGLIBC không còn được phát triển vì "các mục tiêu hiện đang được giải quyết trực tiếp trong GLIBC".

Tháng 7 năm 2017, 30 năm sau khi bắt đầu glibc, Roland McGrath tuyên bố ra đi, "tuyên bố bản thân là người duy trì danh dự và rút khỏi tham gia trực tiếp vào dự án. Những tháng qua, nếu không phải là vài năm trước, đã chứng minh rằng bạn không cần tôi nữa ".[3]

Lịch sử phiên bản

Với phần lớn các hệ thống, các phiên bản của glibc có thể được lấy bằng cách thực thi tệp lib (ví dụ, /lib/libc.so.6).

Chức năng

glibc cung cấp chức năng được yêu cầu bởi Single UNIX Specification, POSIX (1c, 1d, và 1j) và một số chức năng được yêu cầu bởi các giao diện ISO C11, ISO C99, Berkeley Unix (BSD), System V Interface Definition (SVID) và X/Open Portability Guide (XPG), Issue 4.2, với tất cả các phần mở rộng chung cho các hệ thống tuân thủ XSI (X/Open System Interface) cùng với tất cả các phần mở rộng X/Open UNIX.

Ngoài ra, glibc còn cung cấp các phần mở rộng đã được cho là hữu ích hoặc cần thiết trong khi phát triển GNU.

Phần cứng và nhân được hỗ trợ

glibc được sử dụng trên nhiều kiến trúc phần cứng và hạt nhân khác nhau. Nó được sử dụng phổ biến nhất trên các hệ thống sử dụng Linux kernel trên phần cứng x86, tuy nhiên, các phần cứng được hỗ trợ chính thức[36] bao gồm: ARM 32-bit và 64-bit (AArch64), C-SKY, DEC Alpha, IA-64, Motorola m68k, MicroBlaze, MIPS, Nios II, PA-RISC, PowerPC, RISC-V, s390, SPARC, và x86 (câc bản cũ hỗ trợ TILE). Nó chính thức hỗ trợ hạt nhân Hurd và Linux. Ngoài ra, có các phiên bản được heavily patched chạy trên hạt nhân của FreeBSD và NetBSD (từ đó các hệ thống Debian GNU/kFreeBSD và Debian GNU/NetBSD được xây dựng tương ứng), cũng như phiên bản phân nhánh của OpenSolaris.[37] Nó cũng được sử dụng (ở dạng đã chỉnh sửa) và được đặt tên là libroot.so trên BeOS vàHaiku.[38]

Dùng trên các thiết bị nhỏ

glibc đã bị chỉ trích là "cồng kềnh" và chậm hơn các thư viện khác trong quá khứ, ví dụ Linus Torvalds[39] và các nhà phát triển embedded Linux. Vì lý do này, một số thư viện chuẩn C thay thế đã được tạo ra để which nhấn mạnh một dấu chân nhỏ hơn. Tuy nhiên, nhiều dự án thiết bị nhỏ sử dụng GNU libc thay vì các lựa chọn thay thế nhỏ hơn vì hỗ trợ ứng dụng, tuân thủ các tiêu chuẩn và tính hoàn chỉnh của nó. Các ví dụ bao gồm Openmoko[40] và Familiar Linux cho các thiết bị cầm tay iPaq (khi sử dụng phần mềm hiển thị GPE).[41]

Lớp tương thích

Có các lớp tương thích ("shims") cho phép chương trình được viết cho các hệ sinh thái khác chạy trên chạy trên các hệ thống cung cấp giao diện glibc. Chúng bao gồm libhybris, một lớp tương thích cho Bionic của Android, và Wine, có thể được coi là lớp tương thích từ Windows API đến glibc và các API gốc khác có sẵn trên các hệ thống tương tự Unix.

Xem thêm

Chú thích

  1. ^ Corbet, Jonathan (28 tháng 3 năm 2012). “A turning point for GNU libc”. LWN.net.
  2. ^ “sourceware.org Git - glibc.git/blob - COPYING.LIB”. sourceware.org. Truy cập ngày 13 tháng 9 năm 2017.
  3. ^ a b “Roland McGrath bows out as glibc maintainer [LWN.net]”. lwn.net. 7 tháng 7 năm 2017. Truy cập ngày 8 tháng 7 năm 2017.
  4. ^ “GNU's Bulletin, vol. 1 no. 4, February, 1988”. Most libraries are done. Roland McGrath […] has a nearly complete set of ANSI C library functions. We hope they will be ready some time this spring.
  5. ^ “GNU's Bulletin, vol. 1 no. 12”. It now contains all of the ANSI C-1989 and POSIX.1-1990 functions, and work is in progress on POSIX.2 and Unix functions (BSD and System V)
  6. ^ Corbet, Jonathan (28 tháng 3 năm 2012). “A turning point for GNU libc”. LWN.net. Of the nearly 19,000 commits found in the project's git repository (which contains changes back to 1995), over 12,000 were made by Ulrich.
  7. ^ “Forking: it could even happen to you”. 12 tháng 9 năm 2008. the split between GNU LIBC and the Linux LIBC -- it went on for years while Linux stabilized, and then the forks re-merged into one project
  8. ^ Lee, Elliot (2001). “A Technical Comparison of glibc 2.x With Legacy System Libraries”. Bản gốc lưu trữ ngày 11 tháng 4 năm 2004.
  9. ^ “Fear of Forking essay, see "6. glibc --> Linux libc --> glibc"”.
  10. ^ “Fear of Forking, footnote on Stallman's merge comments”.
  11. ^ “glibc homepage”. In 2001 The GNU C Library Steering Committee …, was formed and currently consists of Mark Brown, Paul Eggert, Andreas Jaeger, Jakub Jelinek, Roland McGrath and Andreas Schwab.
  12. ^ “Ulrich Drepper”. LinkedIn. Truy cập ngày 13 tháng 6 năm 2012.
  13. ^ Drepper, Ulrich (26 tháng 6 năm 2000). “RMS is at it again”. sourceware.org. Truy cập ngày 20 tháng 11 năm 2015. A few weeks ago RMS started the next attack on me (a single mail, followed by indirect tries to take influence, followed by another mail today). The essence is that he complains I am not following "GNU policies" and therefore have to be replaced by a steering committee of which I could be a part. Some of you (namely Roland and Andreas S.) probably know about this since he proposed both as other members of the committee. In addition there was Mark Brown listed (I know somebody of this name at IBM who would also fit in this group but I'm not sure whether it is really him.) Anyhow, I completely reject this. It is not helping at all, the opposite is true. First, I am not aware of any essential policies I'm violating. The only ones are that I'm not following orders from RMS which clearly have political intends (which is of course a sacrilege) and possibly that I do not care about Winblowz (if the latter counts at all). None of this will change in any way.
  14. ^ Drepper, Ulrich (15 tháng 8 năm 2001). “glibc 2.2.4”. sourceware.com. Truy cập ngày 29 tháng 11 năm 2015. And now for some not so nice things. Stallman recently tried what I would call a hostile takeover of the glibc development. He tried to conspire behind my back and persuade the other main developers to take control so that in the end he is in control and can dictate whatever pleases him. This attempt failed but he kept on pressuring people everywhere and it got really ugly. In the end I agreed to the creation of a so-called "steering committee" (SC).
  15. ^ Drepper, Ulrich (25 tháng 5 năm 2005). “Dictatorship of the Minorities”. udrepper.livejournal.com. Truy cập ngày 15 tháng 1 năm 2012. Which architectures are worthwhile supporting? […]. Not only do we have to look for irrelevance (what percentage cares about Vax, PArisc) support, we also have to look at the level of added complexity the support requires. Some ABIs are just deliberately defined to be different from others (see IA-64) which requires huge amounts of effort to be spent. There are also significantly diverging capabilities (e. g., the lack of atomic operations in too many architectures). This far too often causes to unnecessarily crippled code since writing code in a way which allows optimal use in all situations is very difficult. The solution must be to restrict support to only a handful of architectures which are supported in the project. All other support must happen outside the tree and therefore all the work has to be done by the special interest groups. I don't want to say we follow all these points perfectly, but for a big project glibc certainly comes closest to this.
  16. ^ Jarno, Aurélien (5 tháng 5 năm 2009). “Debian is switching to EGLIBC”. aurel32.net. Truy cập ngày 15 tháng 1 năm 2012. More friendly upstream (especially with regard to embedded architectures): “Encourage cooperation, communication, civility, and respect among developers” (as opposed to this).
  17. ^ timothy (6 tháng 5 năm 2009). “Debian Switching From Glibc To Eglibc”. Slashdot. Truy cập ngày 14 tháng 1 năm 2012.
  18. ^ McGrath, Roland (26 tháng 3 năm 2012). “glibc steering committee dissolving”. Sourceware.org. Truy cập ngày 13 tháng 6 năm 2012.
  19. ^ Myers, Joseph S. (26 tháng 3 năm 2012). “GNU C Library development and maintainers”. Sourceware.org. Truy cập ngày 13 tháng 6 năm 2012.
  20. ^ “Debian is switching (back) to GLIBC”. Aurélien. 19 tháng 6 năm 2014. Truy cập ngày 19 tháng 6 năm 2014.
  21. ^ “CosmicCuttlefish/ReleaseNotes - Ubuntu Wiki”.
  22. ^ “Chapter 5. RHEL 8.0.0 release Red Hat Enterprise Linux 8”.
  23. ^ “Chapter 2. What's new in Debian 10”.
  24. ^ “Changes/GLIBC228”.
  25. ^ “Red Hat Bugzilla – Bug 1598403”.
  26. ^ “sourceware.org Git - glibc.git/blob - NEWS”.
  27. ^ “DiscoDingo/ReleaseNotes - Ubuntu Wiki”.
  28. ^ “Changes/GLIBC229”.
  29. ^ “Red Hat Bugzilla – Bug 1653403”.
  30. ^ “sourceware.org Git - glibc.git/blob - NEWS”.
  31. ^ “EoanErmine/ReleaseNotes - Ubuntu Wiki”.
  32. ^ “Changes/GLIBC230”.
  33. ^ “Focal (20.04) : glibc package : Ubuntu”.
  34. ^ “Changes/GLIBC231”.
  35. ^ “The GNU C Library version 2.32 is now available”. sourceware.org. Truy cập ngày 13 tháng 8 năm 2020.
  36. ^ “The GNU C Library machine maintainers”.
  37. ^ Bartley, David; Spang, Michael. “GNU/kOpenSolaris (GNU libc/base + OpenSolaris kernel)”. Truy cập ngày 16 tháng 12 năm 2008.
  38. ^ “Haiku Source”. libroot.so is not part of GNU project and is included in Haiku source code.
  39. ^ Torvalds, Linus (9 tháng 1 năm 2002). “Posting to the glibc mailing list”.
  40. ^ “OpenMoko components”. We will use glibc (not uClibC) … The alternatives may save more space and be more optimized, but are more likely to give us integration headaches
  41. ^ “Re: [Familiar] Which glibc for Familiar 0.8.4  ?”. Question: which version of the GLIBC was used to build the Familiar 0.8.4 ? Answer: 2.3.3

Liên kết ngoài

Lấy từ “https://vi.wikipedia.org/w/index.php?title=GNU_C_Library&oldid=63786617”