ГНУ Ц библиотека

С Википедије, слободне енциклопедије
(преусмерено са GNU C Library)
ГНУ C библиотека
Програмер(и)Роланд МекГрат, ГНУ пројекат
Прво издање1987. год.; пре 37 година (1987)
Спремиште Уреди на Википодацима
Написан уC
Оперативни системЈуникс
ТипБиблиотека
ЛиценцаGNU Lesser General Public License
Веб-сајтwww.gnu.org/software/libc/
Линукс АПИ је састављена од система приступа (интерфејс), Linux језгра, као и ГНУ ц библиотеке (ГНУ), libdrm, libalsa i libevdev (од стране freedesktop.org).
ГНУ ц библиотека је омотач око система који се зове Линукс језгро.
Линукс језгро и ГНУ ц библиотека  заједно формирају Линукс АПИ. Након сједињавања, нуде бинарне фајлове (датотеке)АБИ.

ГНУ C библиотека, познатија под називом glibc, је ГНУ пројекат направљен од Ц стандардне библиотеке. Упркос свом имену, ова библиотека директно подрзава и C++ (и индиректно друге програмске језике). Основана је 1990-их од стране фондације за слободни софтвер (ФСФ) за њихов ГНУ оперативни систем.

Објављена је од стране GNU Lesser General Public лиценце, и ц библиотека је слободни софтвер.

Историја[уреди | уреди извор]

Ц библиотеку је првобитно написао Роналд МекГрат, који је радио за фондацију за слободни софтвер (ФСФ) 1980-те.

У фебруару 1988, ФСФ, је описао C библиотеку као скоро готову и функсионалну какву ју је захтевао ANSI C.[1] До 1992, имала је ANSI C-1989 и POSIX.1-1990 имплементиране функције и рад се обављао под POSIX.2.[2]

У септембру 1995 Улрик Дрепер је извршио свој први допринос glibc пројеку и постепено постао око 1990-ит главни сарадник и одржавалац glibc-а.[3] Дрепер је имао руководећу улогу током много година и до 2012 је накупио 63% од свих извшавања пројекта.[4]


Развој "Линукс libc-a"[уреди | уреди извор]

У раним 1990-им, програмери Линукс језгра су развили glibc. Њихов форк који се звао "Линукс libc", годинама није одржаван а објављене су верзијама од 2 до 5.

Када је ФСФ објавио glibc верзију 2.0 у Јануару 1997, она је имала много више компајлера по комплетним POSIX стандардима, бољу интернационализација и вишејезичне функције, IPv6 способности, 64-битни приступ подацима, окружења за вишенитне апликације, будуће компатибилне верзије, и кодове веће преносивости.[5] У овом тренутку, програмери Линукс језгра прекидају развој и настављају са даљим коришћењем ФСФ-овог glibc-а.[6]

Последња верзија Линукс libc-а се користила под именом (soname) libc.sо.5. Надаље, glibc 2.x на Линуксу користи soname libc.sо.6[7] (Алфа и IA64 архитектуре сада користе libc.sо.6.1).*.sо име фајла се често мешало са libc6 (на пример у пакету за Дебијаном) пратећи стандардна усвајања за библиотеке.

Према Ричарду Столману, промене које су извршене у Линукс libc-у не могу бити стопљене назад у glibc јер је статус ауторства нејасан, а ГНУ пројекат је веома строг у вези рушења ауторских права и права аутора.[8]

Постављање управног одбора[уреди | уреди извор]

Почевши од 2001. године развоја библиотеке је надгледао одбор,[9] са Улриком Дрепером[10] као главним сарадником и одрживачем. Постављање управног одбора је подлегло јавној расправи и котроверзи и како је отворено описао Улрик Дрепер, пропало непријатељско преузимање од стране Ричарда Столмана.[11][12][13]

Премештање на git[уреди | уреди извор]

Док је пре био у ЦВС-овом складишту, у 2009. glibc је прешао у git-ово складиште на Sourceware.[14]

Дебијан прелази на EGLIBC[уреди | уреди извор]

Након многих контроверзи о Дреперовом стилу управљања и прихватању спољашњег доприноса,[15][16][17] Дебијан је јавно прешао на glibc-ов развој EGLIBC 2009.године.[18]

Распуштање управног одбора[уреди | уреди извор]

У Марту 2012, управни одбор је гласао за то да треба да се распусти а да се уклони Дрепер у корист процеса развоја заједнице, са Рајаном Арнолдом, Максимом Кувyрковим, Јозефом Мајерсом, Карлосом О'Донелом, и Александре Оливом одговорним за одржавање односа са ГНУ (али без додатне моћи одлучивања).[19][20]

Након промене сектора за одржавање glibc-а Дебијан и други пројекти су се вратили назад на glibc, који су се претходно прикључили алтернативама.[21] Такође, од само почетка 2014-те, glibc-ов развој EGLIBC се више није спорводио, откако су "циљеви сада директно усмерени ка GLIBC-у".

Историја верзија[уреди | уреди извор]

За многе системе, верзије glibc-a се могу добити извршавањем либ фајлова (на пример, /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 Дебијан 3.1 (Сарџ)
2.3.3 Децембар 2003
2.3.4 Децембар 2004 Стандард за Линукс стандардну базу (LSB) 3.0 РХЕЛ 4 (Верзија 5)
2.3.5 Април 2005 SLES 9
2.3.6 Новембар 2005 Дебијан 4.0 (Etch)
2.4 Март 2006 Стандард за ЛСБ 4.0, почетна inotify подршка SLES 10
2.5 Септембар 2006 Комплетна inotify подршка РХЕЛ 5
2.6 Мај 2007
2.7 Октобар 2007 Дебијан 5 (Лени), Убунту 8.04
2.8 Април 2008
2.9 Новембар 2008
2.10 Maj 2009
2.11 Октобар 2009 SLES 11, Убунту 10.04, eglibc коришћен u Дебијан 6
2.12 Maj 2010 РХЕЛ 6
2.13 Јануар 2011 eglibc 2.13 коришћен у Дебијан
2.14 Јун 2011
2.15 Март 2012 Убунту 12.04 и 12.10
2.16 Јун 2012 x32 подржан, ISO C11 приджавање, SystemTap
2.17 Децембар 2012 64-bit AR Убунту 13.04, РХЕЛ 7
2.18 Август 2013 Побољшан C++11 подржан. Подржан за интел ТСХ. Подржан за Хиликс MicroBlaze и IBM POWER8 микроархитектура. Федора 20
2.19 Фебруар 2014 SystemTap пробе за malloc. ГНУ Индиректна функција (ИФУНЦ) подрзана за ppc32 и ppc64. Нова моућност macro _DEFAULT_SOURCE за замену _SVID_SOURCE и _BSD_SOURCE. Прелиминарна сигурна документација за све мануелне функције. ABI промена ucontext-а и jmp_buf за s390/s390x. Убунту 14.04, eglibc 2.19 коришћен за Дебијан 8
2.20 Септембар 2014 Подршка за опис фајла Федора 21
2.21 Фебруар 2015 Нова семафор имплементација Убунту 15.04, пробни Дебијан, Федора 22
2.22 Август 2015 Google Native Client (NaCl) за рад на ARMv7-A, Unicode 7.0 Федора 23

Подржани хардвери и језгра[уреди | уреди извор]

Glibc се користи у системима који користе много различитих језгара и различите хардверске архитектуре. Његова најчешћа употреба је у системима који користе Линукс језгро на x86 хардверу, међутим, званично подржавани хардвери[22] укључују: ARM архитектура, DEC AlphaPA-RISCIA-64, Моторола м68кMicroBlaze, MIPS, Nios II, PowerPC, s390, SPARC, TILE, и x86. Она такође званично подржава Хурд и Линукс језгра. Поред тога, постоје закрпљене верзије које раде на језгрима FreeBSD и NetBSD (од којих се Дебијан ГНУ /kFreeBSD и Дебијан ГНУ/NetBSD системи граде, респективно), као и развојна-верзија OpenSolaris.[23] Он се такође користи (у облику едитора), а назван је  libroot.so у BeOS-у и Haiku-у.[24]

Функционалност[уреди | уреди извор]

Glibc обезбеђује потребну функционалност од стране  Single UNIX Specification-а, Посикс-а (1c, 1d, и 1j) и неке функционалности базиране на ISO-у C11, ISO C99, Беркли Јуникс (BSD) окружења, System V Interface Definition (СВИД) и X/Open Portability Guide (XПГ), издање 4.2, са свим наставцима заједничких XSI (X/Open System Interface) у складу система са свим X/Open UNIX екстензијама.

Такође, glibc омогућава и екстензије које су биле неопходне приликом стварања ГНУ-а.

Коришћење у мали уређајима[уреди | уреди извор]

Glibc је критикован као "напумпан" и спорији је од других библиотека које су коришћене у прошлости, на пример, критикован је од стране Линуса Торвалдса[25] и програмера уграђеног Линукса. Из тог разлога, створено је неколико алтернативних C стандарда који остављају мање последице. Алтернативне библиотеке су Bionic (базирана углавном на библиотекама из BSD и коришћеним у Андроиду[26]), dietlibc, uClibc, Newlib, Klibc, и musl.

Међутим, многи пројекти мањих уређаја пре користе ГНУ libc над мањим алтернативама због подршке апликација, усклађености са стандардима и због комплетности. Пример укључује Openmoko[27] и Familiar Linux за iPaq диктафоне (када користе ГПЕ графику софтвера).[28]

Види још[уреди | уреди извор]

Референце[уреди | уреди извор]

  1. ^ "https://www.gnu.org/bulletins/bull4.html".
  2. ^ "GNU's Bulletin, vol. 1 no. 12".
  3. ^ glibc changelog[мртва веза] on github.com
  4. ^ Corbet, Jonathan (28. 3. 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.' 
  5. ^ Lee, Elliot (2001).
  6. ^ "Forking: it could even happen to you". 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
  7. ^ "Fear of Forking essay, see "6. glibc --> Linux libc --> glibc"".
  8. ^ "Fear of Forking, footnote on Stallman's merge comments".
  9. ^ „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. 
  10. ^ „Ulrich Drepper”. LinkedIn. Приступљено 13. 6. 2012. 
  11. ^ Drepper, Ulrich (26. 6. 2000). „RMS is at it again”. sourceware.org. Приступљено 20. 11. 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.' 
  12. ^ Drepper, Ulrich (15. 8. 2001). „glibc 2.2.4”. sourceware.com. Приступљено 29. 11. 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).' 
  13. ^ rms-accused-of-attempting-glibc-hostile-takeover on slashdot.com on August 19, 2001
  14. ^ glibc repo on Sourceware.com
  15. ^ Ulrich Drepper 2007-10-03 06:13:55 UTC "This has nothing to do with "x86 only". All ABIs designed by people who have a bit of understanding require no change. Any change will negatively impact well designed architectures for the sole benefit of this embedded crap. But your own version of the file in the add-on."
  16. ^ Drepper, Ulrich (25. 5. 2005). „Dictatorship of the Minorities”. udrepper.livejournal.com. Приступљено 15. 1. 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.' 
  17. ^ Jarno, Aurélien (5. 5. 2009). „Debian is switching to EGLIBC”. aurel32.net. Приступљено 15. 1. 2012. „'More friendly upstream (especially with regard to embedded architectures): “Encourage cooperation, communication, civility, and respect among developers” (as opposed to this).' 
  18. ^ timothy (6. 5. 2009). „Debian Switching From Glibc To Eglibc”. Slashdot. Приступљено 14. 1. 2012. 
  19. ^ McGrath, Roland (26. 3. 2012). „glibc steering committee dissolving”. Sourceware.org. Приступљено 13. 6. 2012. 
  20. ^ Myers, Joseph S. (26. 3. 2012). „GNU C Library development and maintainers”. Sourceware.org. Приступљено 13. 6. 2012. 
  21. ^ „Debian is switching (back) to GLIBC”. Aurélien. 19. 6. 2014. Приступљено 19. 6. 2014. 
  22. ^ "The GNU C Library machine maintainers."
  23. ^ Bartley, David; Spang, Michael.
  24. ^ "Haiku Source". libroot.so is not part of GNU project and is included in Haiku source code.
  25. ^ Torvalds, Linus (9 January 2002).
  26. ^ "Bionic libc README".
  27. ^ "OpenMoko components" Архивирано на сајту Wayback Machine (22. април 2016).
  28. ^ "Re: [Familiar] Which glibc for Familiar 0.8.4 ?"

Спољашње везе[уреди | уреди извор]