Представлен (http://sourceware.org/ml/libc-alpha/2012-06/msg00807.html) релиз системной библиотеки GNU C Library (glibc) 2.16 (http://sourceware.org/glibc/wiki/Release/2.16), которая полностью следует требованиям стандартов ISO C99, C11 и POSIX.1-2008. Новая версия примечательна реализацией поддержки стандарта C11, поддержкой X32 ABI, проведением чистки кода (оставлена только поддержки EABI для ARM, из бинарных форматов сохранена только поддержка ELF, убран код совместимости со старыми ядрами Linux), перемещением в порты архитектуры IA-64, ревизией математических функций, поддержкой архитектур TILE-Gx и TILEPro.
Glibc является основой большинства Linux-дистрибутивов, за исключением OpenWrt, Debian и Ubuntu, которые перешли на использование системной библиотеки Eglibc (http://www.eglibc.org). Библиотека Eglibc построена на актуальной кодовой базе Glibc и полностью совместима с ней на уровне API и ABI, отличаясь (http://www.eglibc.org/faq) интеграцией некоторых дополнительных наработок для встраиваемых систем, более низкими системными требованиями, возможностью гибкой настройки компонентов, улучшенной поддержкой кросс-компиляции и кросс-тестирования.В новой версии Glibc произошли следующие изменения (http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;h...):
- Для архитектуры x86-64 добавлена поддержка X32 ABI (http://sites.google.com/site/x32abi/), позволяющего использовать на 64-разрядных системах 32-разрядную модель адресации памяти. ABI X32 позволяет приложениям использовать все преимущества архитектуры x86_64, такие как дополнительные регистры и более быстрые инструкции, PIC ABI. В то же время ABI X32 даёт возможность работать с 32-разрядными указателями памяти, что позволяет экономить память, способствует более эффективному наполнению процессорного кэша и положительно сказывается на общей скорости исполнения кода;
- Реализована поддержка нового стандарта языка Си - C11 (http://www.opennet.me/opennews/art.shtml?num=32644) (ISO / IEC 9899:2011):
- Добавлена поддержка статических утверждений static_assert (http://www.robertgamble.net/2012/01/c11-static-assertions.html);
- В режиме совместимости с C11 удалена функция gets();
- Добавлены функции at_quick_exit() (http://blog.smartbear.com/software-quality/bid/173187/C11-A-...) и quick_exit();
- Добавлена функция aligned_alloc() (http://www.drdobbs.com/cpp/240001401);
- Реализована возможность управления выравниванием выделяемой памяти через функцию aligned_alloc();
- Добавлены функции преобразования Unicode-строк uchar.h;
- Добавлены комплексные функции CMPLX, CMPLXF, CMPLXL;- Поддержка архитектуры IA-64 перемещена из основной ветки в порты;
- Убрана поддержка всех бинарных форматов, кроме ELF;
- Добавлена проверка версий для вызовов poll() и ppoll();
- Увеличена скорость выполнения некоторых математических функций в режиме x86-64;
- Добавлен флаг компиляции "--enable-obsolete-rpc", который включает поддержку устаревших RPC-функций, которые присутствовали в glibc 2.14 и ранее;
- Убран код совместимости с ядрами Linux до версии 2.4. Разработчики предупреждают, что glibc 2.16 гарантирует совместимость только с ядрами 2.6.x и более поздними;
- Добавлен новый заголовок sys/auxv.h и функция getauxval() для лёгкого доступа к информации пар параметр/значение AT_* ядра Linux;
- Оптимизирована функция expf() для платформ x86 и x86-64. Работа выполнена Любовью Дмитриевой, российским разработчиком из Intel;
- Улучшена поддержка кросс-компиляции;
- Добавлена поддержка процессорных архитектур TILE-Gx и TILEPro;
- Убрана поддержка старых версий ARM ABI, теперь поддерживается только EABI;
- Обеспечена совместимость конфигурационных заголовочных файлов между архитектурами x86 и x86-64;- Добавлена сборочная опция "--enable-systemtap" для включения статических проверок setjmp в libc и longjmp в libpthread, необходимых для трассировки приложений при помощи SystemTap;
- Добавлены новые оптимизированные варианты функций для архитектур SPARC и PowerPC;- Проведён аудит работы математических функций, устранены многие проблемы, приводившие к появлению неточных результатов;
- В поставку больше не входя файлы с данными по часовым поясам, базу часовых поясов теперь нужно устанавливать отдельно (ftp://munnari.oz.au/pub/);
- Исправлено 253 ошибки.URL: http://sourceware.org/ml/libc-alpha/2012-06/msg00807.html
Новость: http://www.opennet.me/opennews/art.shtml?num=34191
Знаковый релиз.
Без комитета, с С11, х32,…
> Без комитетаобьясните что с ним случилось
http://www.h-online.com/open/news/item/The-GNU-C-Library-Ste...Лень на opennet.ru искать - новость была, а вот тег, видимо, Макс забыл поставить ))
вторая ссылка под новостью.
>Без комитета, с C11Implemented by Ulrich Drepper ;)
> OpenWrtРазве у них не uClibc?
Зависит от платформы для которой собирается.
И от софта. Некоторый софт явно требует более крупную либу.
Ни слова об слиянии с eglibc :( Может кто знает, до чего договорились разработчики glibc и eglibc на текущий момент? Будет слияние или нет?
Нет, а зачем."Contributors to EGLIBC should consider contributing to GLIBC. If the GLIBC maintainers accept the contribution, it will find its way into EGLIBC because the EGLIBC maintainers regularly merge GLIBC changes into EGLIBC. Because all changes to EGLIBC meet the FSF's requirements for inclusion in GLIBC, the GLIBC maintainers are always free to incorporate EGLIBC changes."
Чтобы не тратить время на> the EGLIBC maintainers regularly merge GLIBC changes into EGLIBC
и
> the GLIBC maintainers are always free to incorporate EGLIBC changes
так а кому не тратить то?
разрабам EGLIBC?смотрю на сабж и понимаю, что изменений и так не мало, чтобы ещё и об EGLIBC заботиться.
будет менее кардинальных изменений, может и заморочаються этим вопросом. чтобы разрабам EGLIBC легче жилось. :D
> так а кому не тратить то?
> разрабам EGLIBC?Да.
> будет менее кардинальных изменений, может и заморочаються этим вопросом. чтобы разрабам
> EGLIBC легче жилось. :DИрония не в тему.
почему?у разрабов glibc есть как бы свои планы и желания. и эти планы и желания появились в очередной версии (см. сабж)
у разрабов eglibc есть свои планы и желания.
если они хотят сотрудничать, то пусть их продвигают либо у себя, либо подключаются к glibc.
тем более, что комитет самораспустился, а разрабы glibc сказали им велкам_к_нам.
нет слияния с eglibc в сабже? ну значит никто на велкам не отозвался. в любом случае это вопрос к разрабам eglibc, а не к glibc.
> тем более, что комитет самораспустился, а разрабы glibc сказали им велкам_к_нам.Распустился коммитет glibc, что для eglibc как-то перпендикулярно :)
ну а на нет и суда нет :D
> у разрабов glibc есть как бы свои планы и желания
> у разрабов eglibc есть свои планы и желания.
> если они хотят сотрудничать, то пусть их продвигают либо у себя, либо
> подключаются к glibc.Всё это не противоречит тому, что от объединения выиграли бы все.
Как и от мира во всём мире.
Зыж
А да! Не все! :D
Но это как Марии Тэрезе выдвигать претензии по фактам насилия американских пехотинцев в Ираке.
Нафлеймили кучу необоснованных домыслов :)Сам спросил, сам и отвечу:
http://www.eglibc.org/archives/patches/msg01129.htmlI am gradually working on merging EGLIBC changes to glibc (generally reworking them in the process). If at the end of the process there are still changes in EGLIBC that it has been concluded are inappropriate for glibc (but are still desired for EGLIBC) then I think it will be appropriate to set up rebased git trees for EGLIBC, based on glibc git with only the remaining patches applied as logical commits for each logical change still present in EGLIBC relative to glibc. I hope however the result may be that a separate EGLIBC source tree is no longer needed and the repository is only needed for past release branches, in which case I don't think it will be worth setting up a git repository for EGLIBC.
Unless your change depends on something that is only in EGLIBC, not glibc, I advise contributing to glibc in the first instance; I continue to make routine merges from glibc to EGLIBC.
Если кратко и по-русски: счастливое будущее неизбежно.
Ура товарищи!
> Ни слова об слиянии с eglibc :(Учитывая как они раньше себя вели это и не удивительно. Eglibc - это такой форк glibc созданный в результате наличия в glibc господ типа Дреппера. Впрочем, учтя что он кажется свалил и вообще политика glibc несколько пересмотрена - оно может уже и не так нереально.
Ульрих никуда не ушёл, он место работы поменял - его патчей в glibc море.Политика вряд ли кардинально поменялась.
> Ульрих никуда не ушёл, он место работы поменял - его патчей в glibc море.Он вроде теперь не сможет так же нагло всех слать. Но..
> Политика вряд ли кардинально поменялась.
...вот это - скорее всего факт. Поэтому пусть уж eglibc живет отдельно. А то всякие "а, да подумаешь - ынтырпрайзы упали! Я прав и все тут!" или "а вот на ARM в вашей либе - баг! Ничего не знаем, этот ваш арм - дeрьмo, мы не поддерживаем его, сами разбирайтесь!". А потом они еще удивляются почему в openwrt - ucLibc и/или eglibc. Для них ARM - нормально. Как впрочем и MIPS. Или что там у кого еще есть.
> Он вроде теперь не сможет так же нагло всех слать.что печально. потому что другого языка идиоты не понимают.
> А то всякие «а, да подумаешь — ынтырпрайзы упали! Я прав и все тут!»
и что характерно — действительно, прав.
> А потом они еще удивляются почему в openwrt — ucLibc и/или eglibc.
кто «они»?
> А потом они еще удивляются почему в openwrt - ucLibc и/или eglibc.Действительно, кто "они"? Что-то не помню, что glibc позиционировалась как libc библиотека для embedded систем. Тратить ресурсы на десктоп/сервера и на embedded приведет к тому, то ни одно ни другое нормально развиваться не сможет, а коли сможет, то медленней.
> Eglibc - это такой форк glibc созданный в результате наличия в glibc господ типа Дреппера.Неа. Учите матчасть.
Разработчики eglibc ничего не имеют против Дреппера. Все, что они хотели - собирать урезанные версии glibc для встраиваемых систем.
> Разработчики eglibc ничего не имеют против Дреппера.Вообще, люди типа Торвальдса, Поттеринга, Дреппера - не нравятся только агрессивным, но не разбирающимся в матчасти анонимам. Среди коллег-разработчиков их как минимум уважают, и никаких крестовых походов никогда не устраивают.
хм. а по-моему, как раз тем, кто в матчасти разбирается, портеринг и не нравится. а вот неразбирающиеся хомячки за него горой.
> хм. а по-моему, как раз тем, кто в матчасти разбирается, портеринг и не нравится. а вот неразбирающиеся хомячки за него горой.Наоборот. Например, часто встречающееся заявление "без /usr все нормально грузится" является безусловным признаком незнания матчасти. Я уж не говорю про "прозрачность" shell-скриптов и "необходимость изучать си для редактирования юнитов".
Аналогично и с Дреппером. Как правило, на него гонят ровно те же самые хомячки.
>как раз тем, кто в матчасти разбираетсяи это ни на долю секунды не про тебя