Библиотека GNU C , широко известная как glibc , является реализацией стандартной библиотеки C в рамках проекта GNU . Несмотря на свое название, теперь он также напрямую поддерживает C ++ (и, косвенно, другие языки программирования ). Он был основан в 1980-х годах Фондом свободного программного обеспечения (FSF) для операционной системы GNU .
Автор (ы) оригинала | Роланд МакГрат |
---|---|
Разработчики) | Проект GNU |
Первый выпуск | 1987 [1] |
Стабильный выпуск | 2.33 [2] (1 февраля 2021 г . ) [±] |
Репозиторий | |
Написано в | C |
Операционная система | Unix-подобный |
Тип | Библиотека времени исполнения |
Лицензия | Начиная с версии 2.2.4: LGPL-2.1 или более поздней версии [3] [4] 0.1? до 2.2.3: LGPL-2.0 или новее [5] |
Веб-сайт | www |
Выпущенный под GNU Lesser General Public License , [3] Glibc является свободным программным обеспечением . Проект GNU C Library предоставляет базовые библиотеки для системы GNU, а также для многих систем, использующих Linux в качестве ядра . Эти библиотеки предоставляют важные API-интерфейсы, включая ISO C11 , POSIX.1-2008 , BSD , API-интерфейсы для конкретных ОС и другие. Эти API включают в себя такие базовые возможности, как open , read , write , malloc , printf , getaddrinfo , dlopen , pthread_create , crypt , login , exit и другие.
История
Первоначально проект glibc был написан в основном Роландом МакГратом, который в подростковом возрасте работал в Free Software Foundation (FSF). [6] В феврале 1988 года, ФФС описано Glibc как будто они почти завершили функциональные возможности, необходимые ANSI C . [7] К 1992 году в нем были реализованы функции ANSI C-1989 и POSIX.1-1990, и работа над POSIX.2 велась. [8] В сентябре 1995 года Ульрих Дреппер сделал свой первый вклад в glibc, и к 1997 году большая часть коммитов была сделана им. Дреппер много лет занимал должность сопровождающего и до 2012 года собрал 63% всех коммитов по проекту. [9]
В мае 2009 года glibc был перенесен в репозиторий Git . [9]
Linux libc
В 1994 году разработчики ядра Linux разделили glibc. Их форк, "Linux libc", поддерживался отдельно примерно до 1998 года. Поскольку авторских прав было недостаточно, изменения не могли быть объединены обратно в GNU Libc. [10]
Когда в январе 1997 года FSF выпустила glibc 2.0, разработчики ядра прекратили поддержку Linux libc из-за превосходного соответствия glibc 2.0 стандартам POSIX. [11] glibc 2.0 также имел лучшую интернационализацию и более глубокую трансляцию, возможности IPv6 , 64-битный доступ к данным, возможности для многопоточных приложений, совместимость с будущими версиями и более переносимый код. [12]
Последняя использованная версия Linux libc использовала внутреннее имя ( soname ) libc.so.5 . Исходя из этого, glibc 2.x в Linux использует soname libc.so.6 [13] [ необходим лучший исходный код ]
Руководящий комитет
Начиная с 2001 года развитие библиотеки контролировалось комитетом [14], при этом Ульрих Дреппер [15] оставался ведущим участником и сопровождающим. Создание руководящего комитета вызвало общественные споры, так как Ульрих Дреппер открыто охарактеризовал его как неудачный маневр враждебного поглощения, совершенный Ричардом Столлманом. [16] [17] [18]
В марте 2012 года руководящий комитет проголосовал за роспуск и удаление Drepper в пользу процесса разработки, управляемого сообществом, при этом Райан Арнольд, Максим Кувырков, Джозеф Майерс, Карлос О'Донелл и Александр Олива несут ответственность за поддержку GNU (но без дополнительных полномочий для принятия решений). [19] [20]
В июле 2017 года, через 30 лет после создания glibc, Роланд МакГрат объявил о своем уходе, «объявив себя почетным сопровождающим и отказавшись от прямого участия в проекте. Последние несколько месяцев, если не последние несколько лет, доказали, что вы этого не сделаете. нужен мне больше ". [6]
Переключатели Debian
После долгих споров о стиле руководства Дреппера и принятии внешнего вклада [21] [22] [23] Debian публично перешел на форк glibc EGLIBC в 2009 году [24] и вернулся к glibc с выпуском Debian 8.0 (Jessie) в апреле 2015 года. [25]
История версий
Для большинства систем версию glibc можно получить, выполнив файл lib (например, /lib/libc.so.6).
Версия | Дата | Заметки | Принятие |
---|---|---|---|
0,1 - 0,6 | Октябрь 1991 - февраль 1992 | ||
1.0 | Февраль 1992 г. | ||
1.01 - 1.09.3 | Март 1992 г. - декабрь 1994 г. | ||
1,90 - 1,102 | Май 1996 - январь 1997 | ||
2.0 | Январь 1997 г. | ||
2.0.1 | Январь 1997 г. | ||
2.0.2 | Февраль 1997 г. | ||
2.0.91 | Декабрь 1997 г. | ||
2.0.95 | Июль 1998 г. | ||
2.1 | Февраль 1999 г. | ||
2.1.1 | Март 1999 г. | ||
2.2 | Ноябрь 2000 г. | ||
2.2.1 | Январь 2001 г. | ||
2.2.2 | Февраль 2001 г. | ||
2.2.3 | Март 2001 г. | ||
2.2.4 | Июль 2001 г. | ||
2.3 | Октябрь 2002 г. | ||
2.3.1 | Октябрь 2002 г. | ||
2.3.2 | Февраль 2003 г. | Debian 3.1 (Sarge) | |
2.3.3 | Декабрь 2003 г. | ||
2.3.4 | Декабрь 2004 г. | Стандарт для Linux Standard Base (LSB) 3.0 | RHEL 4 (Обновление 5) |
2.3.5 | Апрель 2005 г. | SLES 9 | |
2.3.6 | Ноябрь 2005 г. | Debian 4.0 (Etch) | |
2,4 | Март 2006 г. | Стандарт для LSB 4.0, начальная поддержка inotify | SLES 10 |
2,5 | Сентябрь 2006 г. | Полная поддержка inotify | RHEL 5 |
2,6 | Май 2007 г. | ||
2,7 | Октябрь 2007 г. | Debian 5 (Ленни), Ubuntu 8.04 | |
2,8 | Апрель 2008 г. | ||
2,9 | Ноябрь 2008 г. | ||
2,10 | Май 2009 г. | ||
2.11 | Октябрь 2009 г. | SLES 11, Ubuntu 10.04, eglibc, используемый в Debian 6 (Squeeze) | |
2,12 | Май 2010 г. | RHEL 6 | |
2,13 | Январь 2011 г. | eglibc 2.13 используется в Debian 7 (Wheezy) | |
2,14 | Июнь 2011 г. | ||
2,15 | Март 2012 г. | Ubuntu 12.04 и 12.10 | |
2,16 | Июнь 2012 г. | Поддержка x32 ABI , соответствие ISO C11 , SystemTap | |
2,17 | Декабрь 2012 г. | 64-битная поддержка ARM | Ubuntu 13.04, RHEL 7 |
2,18 | август 2013 | Улучшена поддержка C ++ 11 . Поддержка блокировки Intel TSX . Поддержка микроархитектур Xilinx MicroBlaze и IBM POWER8 . | Fedora 20 |
2,19 | Февраль 2014 года | SystemTap проверяет наличие malloc . Поддержка косвенной функции GNU (IFUNC) для ppc32 и ppc64. Новый макрос проверки функций _DEFAULT_SOURCE для замены _SVID_SOURCE и _BSD_SOURCE. Предварительная документация по безопасности для всех функций в руководстве. Изменение ABI в ucontext и jmp_buf для s390 / s390x. | Ubuntu 14.04, eglibc 2.19, используемый в Debian 8 (Jessie), openSUSE 13, SLES 12 |
2,20 | Сентябрь 2014 г. | Поддержка блокировок описания файлов | Fedora 21 |
2,21 | Февраль 2015 г. | Новая реализация семафора | Ubuntu 15.04, Fedora 22 |
2,22 | Август 2015 г. | Поддержка включения Google Native Client (NaCl), который изначально работал на x86, работает на ARMv7-A , Unicode 7.0 | Fedora 23 |
2,23 | Февраль 2016 г. | Юникод 8.0 | Fedora 24, Ubuntu 16.04 |
2,24 | Август 2016 г. | Некоторые устаревшие функции были удалены | Fedora 25, Ubuntu 16.10 и 17.04, Debian 9 (Stretch) |
2,25 | Февраль 2017 г. | В getentropy и getrandom функции, и заголовочный файл были добавлены. | Fedora 26 |
2,26 | Август 2017 г. | Повышенная производительность (поточный кеш для malloc), поддержка Unicode 10 | Fedora 27, Ubuntu 17.10 |
2,27 | Февраль 2018 г. | Оптимизация производительности. Поддержка RISC-V . | Fedora 28, Ubuntu 18.04 |
2,28 | Август 2018 г. | statx , renameat2 , Unicode 11.0.0 | Ubuntu 18.10, [26] RHEL 8.0.0, [27] Debian 10 (Buster), [28] Fedora 29 [29] [30] |
2,29 | Февраль 2019 г. |
| Ubuntu 19.04, [32] Fedora 30 [33] [34] |
2.30 | Август 2019 г. | Unicode 12.1.0, динамический компоновщик принимает --preload аргумент для предварительной загрузки общих объектов, gettid функция была добавлена в Linux, поддержка календаря Minguo (Китайская Республика), новая японская эра добавлена в локаль ja_JP, функции распределения памяти не работают, общий размер объекта больше чем PTRDIFF_MAX ; CVE - 2019-7309 и CVE- 2019-9169 исправлены [35] | Ubuntu 19.10, [36] Fedora 31 [37] |
2.31 | Февраль 2020 г. | Первоначальная поддержка стандарта C2x | Ubuntu 20.04, [38] Fedora 32 [39] |
2.32 | Август 2020 г. | Unicode 13.0, атрибут 'access' для улучшения предупреждений в GCC 10, то есть для «помощи в обнаружении переполнения буфера и других выходов за пределы границ» [40] | Ubuntu 20.10, Fedora 33 |
2.33 | Февраль 2021 г. | HWCAPS | Ubuntu 21.04 |
2.34 | TBA | Ubuntu 21.10 |
Функциональность
glibc обеспечивает функциональность, требуемую единой спецификацией UNIX , POSIX (1c, 1d и 1j), а также некоторые функции, необходимые для интерфейсов ISO C11 , ISO C99 , Berkeley Unix (BSD), определения интерфейса System V (SVID) и X / Open Portability Guide (XPG), выпуск 4.2, со всеми расширениями, общими для систем, совместимых с XSI ( X / Open System Interface ), а также со всеми расширениями X / Open UNIX.
Кроме того, glibc также предоставляет расширения, которые были сочтены полезными или необходимыми при разработке GNU .
Поддерживаемое оборудование и ядра
glibc используется в системах, в которых работает много разных ядер и аппаратных архитектур. Чаще всего он используется в системах, использующих ядро Linux на оборудовании x86 , однако официально поддерживаемое оборудование [41] включает: 32-битную ARM и ее новую 64-битную ISA (AArch64) , C-SKY , DEC Alpha , IA-64. , Motorola m68k , MicroBlaze , MIPS , Nios II , PA-RISC , PowerPC , RISC-V , s390 , SPARC и x86 (старые версии поддерживают TILE ). Он официально поддерживает ядра Hurd и Linux . Кроме того, существуют сильно пропатченные версии, которые работают на ядрах FreeBSD и NetBSD (из которых построены системы Debian GNU / kFreeBSD и Debian GNU / NetBSD соответственно), а также разветвленная версия OpenSolaris . [42] Он также используется (в отредактированном виде) и называется libroot.so в BeOS и Haiku . [43]
Использование в небольших устройствах
В прошлом glibc критиковали как « раздутый » и более медленный, чем другие библиотеки, например Линус Торвальдс [44] и программисты встроенного Linux . По этой причине было создано несколько альтернативных стандартных библиотек C , которые подчеркивают меньшую занимаемую площадь. Тем не менее, многие проекты для небольших устройств используют GNU libc вместо небольших альтернатив из-за поддержки приложений, соответствия стандартам и полноты. Примеры включают Openmoko [45] и Familiar Linux для карманных компьютеров iPaq (при использовании программного обеспечения дисплея GPE ). [46]
Слои совместимости
Существуют уровни совместимости (« прокладки »), позволяющие программам, написанным для других экосистем, работать в системах, предлагающих интерфейс glibc. К ним относятся libhybris , уровень совместимости для Android Bionic и Wine , которые можно рассматривать как уровень совместимости от API Windows до glibc и других собственных API, доступных в Unix-подобных системах.
Смотрите также
- Гнулиб
- API ядра Linux
Рекомендации
- ^ Корбет, Джонатан (28 марта 2012 г.). «Поворотный момент для GNU libc» . LWN.net.
- ^ Адхемервал Занелла (1 февраля 2021 г.). «Библиотека GNU C версии 2.33 теперь доступна» (Список рассылки) . Дата обращения 2 февраля 2020 .
- ^ а б "sourceware.org Git - glibc.git / blob - Makefile" . sourceware.org . Проверено 10 июня 2021 года .
LGPL-2.1 или новее в заголовках
- ^ "sourceware.org Git - glibc.git / commit - Обновление до LGPL v.2.1" . sourceware.org . 6 июля 2001 . Проверено 10 июня 2021 года .
LGPL-2.1 или новее в заголовках
- ^ "sourceware.org Git - glibc.git / commit - Первоначальный импорт: Makefile" . sourceware.org . 18 февраля 1995 . Проверено 10 июня 2021 года .
LGPL-2.0 или новее в заголовках
- ^ а б «Роланд МакГрат отказывается от поддержки glibc [LWN.net]» . lwn.net . 7 июля 2017 . Проверено 8 июля 2017 года .
- ^ "Бюллетень GNU, том 1, № 4, февраль 1988 г." .
Большинство библиотек готово. Роланд МакГрат […] имеет почти полный набор функций библиотеки ANSI C. Надеемся, они будут готовы весной этого года.
- ^ "Бюллетень GNU, том 1, № 12" .
Теперь он содержит все функции ANSI C-1989 и POSIX.1-1990, а также ведется работа над функциями POSIX.2 и Unix (BSD и System V).
- ^ а б Корбет, Джонатан (28 марта 2012 г.). «Поворотный момент для GNU libc» . LWN.net.
Из почти 19 000 коммитов, найденных в репозитории проекта git (который содержит изменения до 1995 года), более 12 000 были сделаны Ульрихом.
- ^ «История glibc и Linux libc» . Журнал свободного программного обеспечения . Дата обращения 10 мая 2021 .
- ^ «Разветвление: такое могло случиться даже с вами» . 12 сентября 2008
г. Раскол между GNU LIBC и Linux LIBC - он продолжался годами, пока Linux стабилизировалась, а затем форки снова объединились в один проект.
- ^ Ли, Эллиот (2001). «Техническое сравнение glibc 2.x с устаревшими системными библиотеками» . Архивировано из оригинального 11 апреля 2004 года.
- ^ «Боязнь раздвоения», см. «6. glibc -> Linux libc -> glibc " " .
- ^ "домашняя страница glibc" .
В 2001 году был сформирован Руководящий комитет библиотеки GNU C…, который в настоящее время состоит из Марка Брауна, Пола Эггерта, Андреаса Йегера, Якуба Елинека, Роланда МакГрата и Андреаса Шваба.
- ^ «Ульрих Дреппер» . LinkedIn . Проверено 13 июня 2012 года .
- ^ Дреппер, Ульрих (26 июня 2000 г.). «RMS снова за это» . sourceware.org . Проверено 20 ноября 2015 года .
Несколько недель назад RMS начал очередную атаку на меня (одно письмо, затем непрямые попытки получить влияние, а сегодня - еще одно письмо). Суть в том, что он жалуется, что я не следую «политике GNU» и поэтому должен быть заменен руководящим комитетом, частью которого я мог бы быть. Некоторые из вас (а именно Роланд и Андреас С.), вероятно, знают об этом, поскольку он предлагал обоих в качестве других членов комитета. Вдобавок в списке был Марк Браун (я знаю в IBM кого-то с таким именем, который также подошел бы к этой группе, но я не уверен, действительно ли это он). В любом случае, я полностью отвергаю это. Это совсем не помогает, все наоборот. Во-первых, я не знаю ни одной важной политики, которую нарушаю. Единственное, что я не выполняю приказы RMS, которые явно имеют политические намерения (что, конечно, кощунственно), и, возможно, меня не волнует Винблоуз (если последний вообще имеет значение). Ничего из этого никоим образом не изменится.
- ^ Дреппер, Ульрих (15 августа 2001 г.). "glibc 2.2.4" . sourceware.com . Проверено 29 ноября 2015 года .
А теперь о некоторых не очень приятных вещах. Столмен недавно предпринял попытку того, что я бы назвал враждебным захватом разработки glibc. Он пытался за моей спиной устроить заговор и убедить других основных разработчиков взять под свой контроль, чтобы в конце концов он все контролировал и мог диктовать все, что ему угодно. Эта попытка провалилась, но он продолжал оказывать давление на людей повсюду, и это стало действительно некрасивым. В конце концов я согласился на создание так называемого «руководящего комитета» (СК).
- ^ RMS-обвиняемый-в-попытке-glibc-враждебном захвате на сайте slashdot.com, 19 августа 2001 г.
- ^ Макграт, Роланд (26 марта 2012 г.). "роспуск руководящего комитета glibc" . Sourceware.org . Проверено 13 июня 2012 года .
- ^ Майерс, Джозеф С. (26 марта 2012 г.). «Разработка и сопровождение библиотеки GNU C» . Sourceware.org . Проверено 13 июня 2012 года .
- ^ Ульрих Дреппер 2007-10-03, 06:13:55 UTC «Это не имеет ничего общего с« только x86 ». Все ABI, разработанные людьми, которые немного понимают, не требуют изменений. Любое изменение отрицательно повлияет на хорошо спроектированные архитектуры для единственное преимущество этой встроенной хрени. Но ваша собственная версия файла в аддоне ".
- ^ Дреппер, Ульрих (25 мая 2005 г.). «Диктатура меньшинств» . udrepper.livejournal.com . Проверено 15 января 2012 года .
Какие архитектуры стоит поддерживать? […]. Мы не только должны искать нерелевантность (какой процент заботится о поддержке Vax, PArisc), мы также должны смотреть на уровень дополнительной сложности, который требуется для поддержки. Некоторые ABI просто намеренно определены, чтобы отличаться от других (см. IA-64), что требует огромных усилий. Возможности также существенно расходятся (например, отсутствие атомарных операций в слишком большом количестве архитектур). Это слишком часто приводит к излишнему искажению кода, поскольку писать код таким образом, чтобы его можно было оптимально использовать во всех ситуациях, очень сложно. Решение должно заключаться в том, чтобы ограничить поддержку только горсткой архитектур, которые поддерживаются в проекте. Вся остальная поддержка должна происходить за пределами дерева, и поэтому всю работу должны выполнять группы с особыми интересами. Я не хочу сказать, что мы точно следуем всем этим пунктам, но для большого проекта glibc, безусловно, ближе всего подходит к этому.
- ^ Ярно, Орелиен (5 мая 2009 г.). «Debian переходит на EGLIBC» . aurel32.net . Проверено 15 января 2012 года .
Более дружественный апстрим (особенно в отношении встроенных архитектур): «Поощряйте сотрудничество, общение, вежливость и уважение среди разработчиков» (в отличие от этого).
- ^ Тимоти (6 мая 2009 г.). «Переход Debian с Glibc на Eglibc» . Slashdot . Проверено 14 января 2012 года .
- ^ Журнал изменений пакета Debian
- ^ «CosmicCuttlefish / ReleaseNotes - Ubuntu Wiki» .
- ^ «Глава 5. RHEL 8.0.0, выпуск Red Hat Enterprise Linux 8» .
- ^ «Глава 2. Что нового в Debian 10» .
- ^ «Изменения / GLIBC228» .
- ^ «Red Hat Bugzilla - Ошибка 1598403» .
- ^ "sourceware.org Git - glibc.git / blob - НОВОСТИ" .
- ^ «DiscoDingo / ReleaseNotes - Ubuntu Wiki» .
- ^ «Изменения / GLIBC229» .
- ^ «Red Hat Bugzilla - Ошибка 1653403» .
- ^ "sourceware.org Git - glibc.git / blob - НОВОСТИ" .
- ^ «EoanErmine / ReleaseNotes - Ubuntu Wiki» .
- ^ «Изменения / GLIBC230» .
- ^ «Focal (20.04): пакет glibc: Ubuntu» .
- ^ «Изменения / GLIBC231» .
- ^ «Библиотека GNU C версии 2.32 теперь доступна» . sourceware.org . Дата обращения 13 августа 2020 .
- ^ «Машинные специалисты по сопровождению библиотеки GNU C» .
- ^ Бартли, Дэвид; Спанг, Майкл. «GNU / kOpenSolaris (GNU libc / base + ядро OpenSolaris)» . Проверено 16 декабря 2008 года .
- ^ «Источник хайку» .
libroot.so не является частью проекта GNU и включен в исходный код Haiku.
- ^ Торвальдс, Линус (9 января 2002 г.). "Отправка сообщений в список рассылки glibc" .
- ^ «Компоненты OpenMoko» .
Мы будем использовать glibc (не uClibC)… Альтернативы могут сэкономить больше места и быть более оптимизированными, но с большей вероятностью доставят нам головные боли при интеграции.
- ^ "Re: [Familiar] Какой glibc для Familiar 0.8.4?" .
Вопрос: какая версия GLIBC использовалась для сборки Familiar 0.8.4? Ответ: 2.3.3
Внешние ссылки
- Официальный веб-сайт