После шести месяцев разработки опубликован (https://sourceware.org/ml/libc-alpha/2019-01/msg00723.html) релиз системной библиотеки GNU C Library (http://ftp.gnu.org/gnu/glibc/) (glibc) 2.29 (http://sourceware.org/glibc/wiki/Release/2.29), которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2008. В состав нового выпуска включены исправления от 55 разработчиков.Из добавленных в Glibc 2.29 улучшений (http://sourceware.org/git/?p=glibc.git;a=blob_plain;f=NEWS;h...) можно отметить:
- Добавлена функция getcpu(), позволяющая получить сведения о используемых в настоящий момент CPU и узлах NUMA;
- Для разработчиков дистрибутивов предложены сборочные команды "make localedata" и "make install-locale-files", дающие возможность собрать и установить все имеющиеся локали в форме раздельного набора каталогов с файлами;
- В математические функции exp, exp2, log, log2, pow, sinf, cosf, sincosf и tanf внесены не специфичные для конкретных аппаратных платформ оптимизации;- Добавлена поддержка 32-разрядной процессорной архитектуры C-SKY (http://en.c-sky.com/solution/CPU-IP-shou-quan.htm) (ABIv2), развиваемой одноимённой китайской компанией для создания SoC для различных потребительских устройств. Для работы требуется наличие binutils 2.32, gcc 9.0 и ядра Linux 4.20. Поддерживается два варианта ABI:
"C-SKY ABIv2 soft-float little-endian" и "C-SKY ABIv2 hard-float little-endian";
- Функция reallocarray() (http://manpages.ubuntu.com/manpages/xenial/man3/reallocarray...) перенесена из набора "_BSD_SOURCE" (интерфейсы BSD, которые конфликтуют с POSIX), в набор "_DEFAULT_SOURCE" (интерфейсы, которые включены по умолчанию);
- Добавлены функции posix_spawn_file_actions_addchdir_np (https://docs.oracle.com/cd/E86824_01/html/E54766/posix-spawn...) и
posix_spawn_file_actions_addfchdir_np, применяющие вызовы posix_spawn и posix_spawnp для запуска нового процесса в другом каталоге. Функции добавлены в секцию расширений GNU;- В функциях popen() и system() прекращён вызов обработчиков atfork (http://pubs.opengroup.org/onlinepubs/007904975/functions/pth...), вызываемых до и после выполнения fork(). Данное поведение возможно нарушает POSIX, который в документации на pthread_atfork предписывает обработчиках atfork обрабатывать состояние мьютекс после выполнения форка в многопоточных процессах, но вызовы popen и system не имеют прямого доступа к пользовательским мьютексам;
- Механизм блокировок Transactional Lock Elision (позволяет увеличить масштабируемость блокировок на системах с поддержкой инструкции HTM) теперь включается для процессоров powercp64le, только если применяются новые версии ядра Linux, собранные в режиме PPC_FEATURE2_HTM_NOSC на процессорах с поддержкой HWCAP2 (т.е. если выполняется сброс транзакции перед входом в ядро). Ранее для совместимости со старыми ядрами не сбрасывающими транзакции, Glibc производил данную операцию самостоятельно, что приводило к снижению производительности на новых ядрах;
- В функции strftime изменено применяемое по умолчанию форматирование альтернативного представления года с учётом локали ("%Ey"), которое теперь включает как минимум две цифры (без отбрасывания нулей) по аналогии с "%y". Изменение заметно только для японских локалей, в которых регулярно встречаются годы меньше 10. Для возвращения старого поведения вместе с "%EY" следует использовать флаги '_' и '-', определённые как расширения GNU;
- Пространство имён glibc.tune переименовано в glibc.cpu, а glibc.tune.cpu в glibc.cpu.name;
- Типы элементов pr_uid и pr_gid в структуре elf_prpsinfo из sys/procfs.h приведены в соответствие с типами, используемыми в ядре Linux (размер структуры изменится только для архитектур MicroBlaze, MIPS (n64 ABI), Nios II и RISC-V). Аналогично к типам ядра приведены типы элементов pr_sigpend и pr_sighold структуры elf_prstatus и pr_flag из elf_prpsinfo, но данное изменение затрагивает только MIPS n32 ABI;
- Устаревшие GNU-расширения форматирования в scanf ('%as', '%aS' и
'%a[...]') теперь доступны только при сборке в режимах C89 и C++98 с флагом _GNU_SOURCE, так как они конфликтуют со спецификациями C99 и C++11. В соответствии с рекомендациями POSIX.1-2008 вместо '%as', '%aS' и'%a[...]' следует использовать '%ms', '%mS' и '%m[...]'. Для выявления применения устаревших расширений форматирования можно использовать режим "-Wformat" в GCC;
- Для сборки Glibc теперь требуется наличие GCC 5 и Python 3.4 или более новые версии (для сборки программ, использующих Glibc ограничения на версию GCC не накладываются);
- Устранены уязвимости:
- CVE-2018-19591 (https://security-tracker.debian.org/tracker/CVE-2018-19591) - утечка файловых дескрипторов в if_nametoindex может привести к отказу в обслуживании из-за исчерпание доступных дескрипторов. Утечка проявляется при вызове функции getaddrinfo() с передачей специально оформленного имени хоста;- CVE-2019-6488 (https://security-tracker.debian.org/tracker/CVE-2019-6488) - переполнение буфера при выполнении функции memcpy, проявляющиеся только в окружениях с архитектурой x32 (https://www.opennet.me/opennews/art.shtml?num=49772) (не путать с x86 IA-32). Проблема вызвана ошибкой в ассемблерной вставке, из-за которой параметр size_t записывается в нижние 32 бита часть 64-разрядного регистра без обнуления оставшихся верхних 32 бит;
- CVE-2016-10739 (https://security-tracker.debian.org/tracker/CVE-2016-10739) - блокирована (https://sourceware.org/bugzilla/show_bug.cgi?id=20018) возможность разбора в функции getaddrinfo() адресов IPv4, содержащих произвольный набор символов в конце (например, "127.0.0.1\nTEST"). С одной стороны данное изменение нарушает сложившееся поведение и может привести к нарушению работы приложений, в которых осуществлялся разбор значений из /etc/hosts без разделения адресов. Но с другой стороны, указанная особенность приводила к уязвимостям в приложениях, которые используют getaddrinfo для проверки корректности адресов (getaddrinfo не возвращал ошибку и приложение считало адрес корректным, даже если после него указывались произвольные строки). На практике данная особенность использовалась (https://bugzilla.redhat.com/show_bug.cgi?id=1347549) для подстановки HTTP-заголовков в приложения на базе Python-библиотекеи httplib через передачу в поле адресов значений вида "127.0.0.1\r\nHttp-заголовок". В некоторых web-интерфейсах домашних маршрутизаторов в форме ping-проверки можно было запустить произвольные команды через передачу значений "127.0.0.1;cat /etc/passwd".
URL: https://sourceware.org/ml/libc-alpha/2019-01/msg00723.html
Новость: https://www.opennet.me/opennews/art.shtml?num=50068
> Для сборки Glibc теперь требуется наличие GCC 5 и Python 3.4...Для сборки glibc нужен python!?
Дожили...
А почему нет? Python при всех своих минусах - эффективный инструмент, который здорово повышает продуткивность.
В какой-то момент зацикливание побороть не смогут, и выяснить почему ошибки
Питон при всех своих скромных возможностях тут явный оверкилл.
> А почему нет?openSUSE прекрасно продемонстрировала, насколько это быстро и замечательно!
openssl 1.1.1 и glibc 2.28 не могли быть приняты, из-за python. Python не мог быть принять из-за кучи его говноподелий, вроде python-tornado, который до сих пор не может работать с TLS 1.3, из-за которого не мог быть принят openssl 1.1.1, а также его говноподелия просто не могут работать с новой версией, пока их не исправят, а их сотни!
Если с очередной версий python будут проблемы пр обновлении, то он может заморозить обновления нужных системных пакетов.
А такое встречается всё чаще и чаще! Даже при обновлении gcc7 время заняло меньше, python 3.7 и его основные говноподелия чинили 7 месяцев, и судя по тому, что творится сейчас в Factory (285 ошибок, из которых более 200 по вине python), то полностью до сих пор не дочинили.Вот почему нет!
> эффективный инструмент, который здорово...
... превращает любую ОС в помойку!
Отчасти все верно, и c perl, ruby не лучше.
Но тем не менееeselect python list
Available Python interpreters, in order of preference:
[1] python2.7
[2] python3.5 (uninstalled)
[3] python3.4 (uninstalled)
[4] python3.6 (fallback)И python_targets_pythonX_X решает. Просто этим надо заниматься тем, кто делает дистрибутив.
Ну, гента может себе подзволить вещи, которые в бинарях в принципе не лечатся. Тем более с use-флагами и слотами.
eselect python cleanup
А принять торнадо таким, какой он есть, без TLS 1.3 - что мешает? Или выкинуть его, в конце концов - что мешает? Что мешает не рваться за последней версией питона, и использовать рабочую? У других дистров этов вполне получается.
> А принять торнадо таким, какой он естьPython 3.6 Не работает с openSSL 1.1.1, для его поддержки нужен 3.7.
> без TLS 1.3 - что мешает?Тем, что ради TLS 1.3 и нужен openSSL 1.1.1
> Или выкинуть его, в конце концов - что мешает?Выкинуть нельзя, он нужен другим говноподелиям.
Старый оставить нельзя, так как он не работает с Python 3.7.
С торнадо пришлось откатить на старую версию, пропачить чтобы он работал с новым пихоном и отключить ему TLS 1.3 тесты.
> Что мешает не рваться за последней версией питона, и использовать рабочую?Тем, что старая, как минимум, openSSL 1.1.1 не поддерживает, и с glibc 2.28 какие-то проблемы были.
На вид - совершенно стандратные дистропроблемы. Решение тоже стандартное - там остались на старой версии, здесь слегка пропатчили. Примерно для того дистрибутивы и нужны, чтобы такие штуки разруливать, и питоном они ни разу не ограничиваются. Я бы сказал, что если " glibc 2.28 какие-то проблемы" решаемы (скорее всего - да) - то самым логичным было бы остаться на питоне 3.6 достаточно долго, чтобы всё подтянулось.
> Python 3.6 Не работает с openSSL 1.1.1, для его поддержки нужен 3.7.Забавно, а в генте вполне себе вот прямо сейчас у меня стоит Python-3.6.5 и openssl-1.1.1a.
А glibc какая?
В SRPM для Firefox для CentOS 5 применили хитрый трюк. В системе - GCC 4.1 и 4.4, надо 4.7. В системе - Python 2.4 и 2.6, надо 2.7. Разработчики просто положили арзивы с исходниками GCC и Python в SRPM-ку Firefox!Может с пакетом Glibc в openSUSE поступить так же? Костыль, но ведь решение же...
Я так сделал в домашнем OBS-репозитории так сделал - тоже для Firefox, только для SLES 11. А в Ubuntu 12.04, например, GCC 4.6 - там создали зависимость gcc-mozilla
А просто выкинуть пихон из glibc не проще?
А ещё проще было его не впихивать его туда.
нет, потому что альтернативно-одаренное Оно поднимет писк, что его притесняют."а других разработчиков у меня для вас нет"
Это вы ещё не видели зависимости webkit-gtk, например - perl, python, ruby
> А почему нет?потому что, к сожалению, питон не является стабильным базисом, на котором можно строить работу. Притащишь в проект питон - жди несколько его версий, затем кто-нибудь притащит pip, потом будут проблемы с pip, и все это венчает множество virtualenv сотоварищи. Все это достаточно серьезные минусы питона.
Отдельно взятый python как интерпретатор - неплохой инструмент, но лишь до тех пор, пока не начнешь задаваться вопросом, а какой он версии. И пошло-поехало... Это совсем не sh!
> Для сборки glibc нужен python!?это конечно уродство..
Уж всяко меньшее уродство, чем m4.
Но всяко хуже с точки зрения деплоймента. А для glibc - это более критично.
Тоже резануло. Они там теперь либц хипстерским ninja собирают? Makefile это недостаточно молодёжно?
Самопочин: посмотрел. Не прав. Они перловые и awk'шные генераторы/верификаторы на питонячьи переписали. Ладно, перл непопулярен (хотя код там был читаемый и понятный), но awk-то за что?
Выглядит как изменения ради изменений. Смысла примерно 0.
> Выглядит как изменения ради изменений. Смысла примерно 0.Ну привлечение молодняка/сторонних рук. Тоже цель. Хоть я и не против питона в разработке, но всёже соглашусь, что для системообразующих вещей, вроде glibc / gcc, это какой-то всё-таки перебор.
так от перла-то хоть в итоге полностью избавились? или он все еще тоже нужен?
Лучше выбросить питон и оставить перл. А наворотить на любом языке можно.
>Выглядит как изменения ради изменений. Смысла примерно 0.Возможно, там был лютый говнокод, и новый разработчик не осилил разобраться и переписал с нуля
Например, за то, что по сравнению с awk perl - это образец читабельности? Может, просто не нашлось психов, готовых в этом копаться?
согласен перл ... ну это перл.))) там такого можно наворотить, что другой перловод может не разобраться)) проще переписать.
вы так говорите как-будто это нельзя сделать в любом другом Тьюринг-полном ЯП
знаю . в питоне тоже на одних спецсимволах в регулярках такое можно написать, что это будет смотреться как абракадабра. но перл все же в этом плане круче))
> знаю . в питоне тоже на одних спецсимволах в регулярках такое можно написать, что это будет смотреться как абракадабра. но перл все же в этом плане круче))Потому что perl круче во всем, т.к. представляет свободу разработчику. Как использовать свободу и возможности языка - ответственность на разработчике, а не на языке.
Я как бы о том, что awk страшнее. А перл... там всё плохо, если пытаться что-то средне-крупное пытаться на нём писать. Это я как перловод говорю :-) До тысячи строк - никаких проблем.
с awk точно так же как и с перлом - модные-современные-sjw-псевдоразработчики не умеют ими пользоваться и учиться не хотят. Вместо того чтобы не допускать подобных скудоумков в проект - им создают условия. А потом вы удивляетесь, почему я ненавижу пихон и его апологетов и стараюсь использовать винду везде, где меня интересует результат, а не процесс.
> с awk точно так же как и с перлом - модные-современные-sjw-псевдоразработчики не
> умеют ими пользоваться и учиться не хотят. Вместо того чтобы неПо справедливости, awk губила и продолжает губить ужасно невнятная документация (т.е. man-страница).
В остальном - синтаксис наполовину си-шный, и оформление функций не страшнее, чем во многих прочих.
Издавна делаю на нём малую автоматизацию, если нужно что-то посложнее шелла.
> По справедливости, awk губила и продолжает губить ужасно невнятная документация (т.е.
> man-страница).man страница g++ почему-то ни разу не помогает мне программировать на C++. И даже info не помогло.
А книжку Кернигана и Пайка (и для совсем уж двинутых - http://shop.oreilly.com/product/9781565922259.do) таки да, читать немодно, немолодежно и неинтересно, и Camel Book тоже. Надо скорее-скорее понакопипастить в проект питоновского мусора со stackoverflow, чукчи ведь писатели.
Вот зачем этим неосиляторам дали зеленый свет в столь критичный проект - спросите у Встолмана и прочих.
> Makefile это недостаточно молодёжно?Попробуй написать мэйкфайл, с десятком опций конфигурации, и кросс-копиляцией под разные ОС, архитектуры и т.д. А ещё лучше поотлаживать такой мэйкфайл, когда он что-нибудь натворит.
Имеется ввиду конечно же мэйкфайл сгенерированный каким-нибудь баш-скриптом, иначе придется все новые сишные файлы и хедеры добавлять туда в зависимости ручками, иначе неправильно будет пересобираться. И не забыть про статические либы.
Так что, аутомэйк
enjoy
https://github.com/cisco/openh264/blob/master/Makefile
> копиляцией под разные ОСА по факту, для поддержки непингвина все равно нужна туева хуча патчей.
> Попробуй написать мэйкфайл, с десятком опций конфигурации, и кросс-копиляцией под разные ОС, архитектуры и т.д. А ещё лучше поотлаживать такой мэйкфайл, когда он что-нибудь натворит.
> Имеется ввиду конечно же мэйкфайл сгенерированный каким-нибудь баш-скриптом, иначе придется все новые сишные файлы и хедеры добавлять туда в зависимости ручками,
> иначе неправильно будет пересобираться. И не забыть про статические либы.Старые перд^W "бздуны" почему-то справились:
https://github.com/freebsd/freebsd/blob/master/lib/libc/Make...
Pick the current architecture directory for libc. In general, this is
# named MACHINE_CPUARCH, but some ABIs are different enough to require
# their own libc, so allow a directory named MACHINE_ARCH to override this..if exists(${LIBC_SRCTOP}/${MACHINE_ARCH})
LIBC_ARCH=${MACHINE_ARCH}
.else
LIBC_ARCH=${MACHINE_CPUARCH}
.endif
Такие вещи делались 20 лет назад.
стесняюсь спросить -в каком месте у вас унылоglibc под разные ос, и в каком таком особом месте _мэйкфайлы_ (а не одна-единственная переменная в них) зависят от архитектуры.единственное, для чего там используется по делу автомэйк - для указания --prefix, и еще пары ненужно-параметров, используемых либо при разработке, либо в необычных окружениях, либо неработающих. Остальное - героическая борьба с самим себе придуманными трудностями - как и в 95% случаев остальных использований gnu autotools.
> Имеется ввиду конечно же мэйкфайл сгенерированный каким-нибудь баш-скриптом
а, то есть вы просто не умеете пользоваться мэйком.
если в модных-современных линуксных ядрах еще не доломали make dep, можете посмотреть, как это делают без всякого автомейка те, кто умеют.
разумеется, кое что приходится добавлять руками - а не собирать весь мусор с пола автопылесосом, а потом удивляться, чего это оно так странно собирается.
Сколько новых функциональных сишных файлов вы добавляете в проект? Дайте угадаю - обычно ноль, редко при больших изменениях - пару десятков. Это охрененно сложная работа - аккуратно написать в мэйкфайл что от чего зависит?
>> Makefile это недостаточно молодёжно?
> Попробуй написать мэйкфайл, с десятком опций конфигурации, и кросс-копиляцией под разныеПрисоединяясь к предыдущему оратору, добавлю, что все эти многочисленные опции конфигурации очень-очень часто не стоят выеденного яйца, поскольку исходник рассчитан под одну-единственную (конфигурацию).
Ниндзя - это сборочный бекенд. Без фронтенда в виде CMake бесполезен.
Чаще перед ниндзей всё-таки мезон ставят, хотя симейку всё равно что генерить, насколько я помню.
Так рэдхэт всюду его пропихивала.
К сожалению, да! :-(
RH с каждым годом превращается во всё большего паразита!
В IBM же он превращается!
Посмотри на Mesa, Gnome и его побочные проекты - все они собираются с помощью Meson. В ближайшее время он станет единственным инструментом для сборки этих проектов. Теперь без Python никуда.
> Посмотри на Mesa, Gnome и его побочные проекты - все они собираются
> с помощью Meson. В ближайшее время он станет единственным инструментом для
> сборки этих проектов. Теперь без Python никуда.Я думал что-то полезное собирается, а на гомном и его прожекты наплевать. Пущай собирают.
CMake предлагали?
Давно пора было. Python - современный и развивающийся язык, дружелюбный к разработчику и пользователю. awk и perl - write-only кошмар из восьмидесятых, где их и следует оставить.
> Давно пора было. Python - современный и развивающийся язык, дружелюбный к разработчику
> и пользователю. awk и perl - write-only кошмар из восьмидесятых, где
> их и следует оставить.Лет 15-20 назад примерно так же восторгались перлом, примерно с той же обоснованностью (т.е. её величество мода).
И под каким пистолетом/веществом называют питон "языком, дружелюбным к пользователю" (???!!!)
Это как это - дружелюбный байт-код? Хвостиком виляет, руки облизывает?
Двадцать лет назад слаще редьки ничего не едали, и после упражнений по обходу всех граблей шелла даже перл казался адекватным. Но время идёт, CS развивается с учётом ошибок и неудачных решений прошлого и люди к хорошему привыкают быстро, а на убогое легаси даже смотреть не хотят.
> Двадцать лет назад слаще редьки ничего не едали, и после упражнений по
> обходу всех граблей шелла даже перл казался адекватным. Но время идёт,Ну и сидит шелл как посажен, а уж перла с нами "нет", и питона, я так полагаю, скоро в том же смысле "не будет".
> CS развивается с учётом ошибок и неудачных решений прошлого и люди
CS по факту не наука, а техника. Соответственно, объём "учёта" прошлого" лишь чуть менее, чем полностью, предопределён конъюнктурой.
Погоня за самыми "хорошими" инструментами не имеет конца, правда?
>Давно пора было. Python - древний и убогий язык для ничего, дружелюбный к кодеру пожиратель памяти и кошмар для пользователя.Починил.
Ах да! Питон не тормо...не ест память как не в себя!
Можно пример недревних и неубогих с вашей точки зрения языков программирования? Спасибо.
> Можно пример недревних и неубогих с вашей точки зрения языков программирования? Спасибо.Tcl lua
> архитектурой x32Так ведь на эту архитектуру - забили?
Чтобы забить на архитектуру, надо чтобы она хотя бы была.
он не понял разницу между физической архитектурой 32 бит и программной реализацией x32. ну это нормально.
Musl лучше.
Тем, что тормознее и поддерживает меньше фич?
Musl меньше.
На продакшене в любом случае только glibc
В облаках всех теснит Alpine. На musl и без systemd.
поскольку musl не обкатана так как glibc её редко кто отважится брать в оборот. так как менее предсказуемо.
>поскольку musl не обкатана так как glibc её редко кто отважится брать в оборот. так как менее предсказуемо.Void Linux использует musl. Из тех кто редко отваживается - ты один.