Glibc 2.34

Прекращено использование символических ссылок для привязки устанавливаемых разделяемых объектов к версии Glibc. Подобные объекты теперь устанавливаются как есть (например, libc.so.6 теперь является файлом, а не ссылкой на libc-2.34.so).

In order to support smoother in-place-upgrades and to simplify the implementation of the runtime all functionality formerly implemented in the libraries libpthread, libdl, libutil, libanl has been integrated into libc.

Шо уж мелочиться - давай пихай и libsystemd.so туда же.

добавлена функция closefrom … Эта функция является расширением GNU

Что за враньё, это BSD функция.

диапазон файловых дескрипторов

дескрипторы, которые больше или равны заданному значению

А какой вообще в этом смысл? Или существуют какие-то гарантии, что открываемые подряд дескрипторы будут каждый следующий строго на 1 больше предыдущего? Да даже если такие гарантии и существуют, то они могут даваться только ядром, а не либой; да и wrap around zero при большом аптайме возможен.

Например, при передаче управления другому исполняемому файлу, если нет гарантии, что всё ненужное открывалось с O_CLOEXEC.

Здесь не написанно что «Эта функция является только расширением GNU»

враньё
это BSD функция.

Ты дурачок, и никакого «вранья» тут нет. В BSD системах - это дополнительная функция от BSD. В GNU libc - от GNU.

Недопонял. Каким боком тут закрытие по диапазону? Разве что запускаемый бинарник первым делом будет закрывать [0, INT_MAX], или как?

Существуют гарантии другого, прописаны в каком-то стандарте, а может даже и в нескольких. Ну и во всех известных юниксах так и есть: новый файловый дескриптор (кроме dup2()) всегда создаётся с минимальным свободным номером. И никакого wrap: файловый дескриптор это индекс к какому-то массиву в описании процесса в ядре, их количество ограничено длиной этого массива, хоть сама длина и не фиксирована нигде.

А применение такое: closefrom(3) закроет всё кроме in/out/err, можно добавить ещё что-то незакрываемое под номерами 3 4 итд. Для того, чтобы дочерний процесс не смог злонамеренно или из-за бага воспользоваться утёкшими (в комплекте с открытыми файлами) правами.

например, libc.so.6 теперь является файлом, а не ссылкой на libc-2.34.so

А смысл?

всегда создаётся с минимальным свободным номером

Понял.

closefrom(3)

Ага, про in/out/err забыл. И вызывать предполагается перед exec…() как защиту от собственных ошибок. Ясно.

внесена вся функциональность библиотек libpthread, libdl, libutil, libanl. Теперь для их использования нет необходимости в флагах -lpthread, -ldl, -lutil, -lanl;

Кто-то сказал «musl»?

осталось внести libboost и libastral

проще обновлять например

смысл от держания двух файлов?

Теперь для их использования нет необходимости в флагах -lpthread, -ldl, -lutil, -lanl

а че? так можно было?

Тормозное говно твой musl.

Пруф, что два файла так и не осталось?

http://www.etalabs.net/compare_libcs.html

Теперь для их использования нет необходимости в флагах -lpthread, -ldl, -lutil, -lanl

Наконец-то! Всегда напрягало это бессмысленное жонглирование флагами.

Теперь для их использования нет необходимости в флагах -lpthread

-pthread то всё равно нужен будет?

Не от собственных.

Во-первых, библиотеки могут открывать что-то, но не ожидать fork/exec.

Во-вторых, ты сам можешь унаследовать какие-то лескрипторы от родителя.

Самый яркий пример - это реализация subprocess в питоне. Она после форка открывает пайп и если что передает по нему аргументы или код возврата. Так вот, это было не thread-safe. Если 2 потока пытаются сделать call одновременно, то каждый сделал пайп, потом делается форк перед тем, как второй поток успевает закрыть конец на запись. Получается, что будет открытый дескриптор на запись где-то болтаться, и read будет висеть.

Теперь для их использования нет необходимости в флагах -lpthread, -ldl, -lutil, -lanl;

Ну что, молодцы. Окукливают инфраструктуру чтобы она на другом рантайме не работала. Здравствуй несовместимый между платформами код.

Мозольный вендорлок?

когда, интересно, поттеринг свою альтернативу предложит.

Эта новость должна вызывать ужас у тех, кто пишет кроссплатформерные приложения на С - потому что если сейчас начнут массово игнорировать -lpthread, то собрать эту ересь под винду будет нереально без патчинга сборщика\исходников, что не всегда можно делать по лицензионным причинам. Я уже молчу про вижуалстудию, тот же mingw не соберет утилу без lpthread.

Так что да, это мозольный вендорлок.

С другой стороны должно быть легче для линукс онли среды. Так что история не такая однозначная.

Не стыдно такие вещи в слух говорить?

Эта новость должна вызывать ужас у тех, кто пишет кроссплатформерные приложения на С

Пффф, они столько дерьма повидали, что это им вообще ни о чем.

Ну да, сделать жизнь «легче» (хотя непонятно чем именно, если всё это в системе сборки сто лет назад прописано) для 1%, ухудшив жизнь (сломав совместимость) для 90%.

хорошая ссылка. и действительно, к сожалению, в большинстве тестов musl хуже.

2038 можно считать решенной?

начнут массово игнорировать -lpthread

-lpthread же никогда и не был нужен, или я чего-то не знаю?

-pthread без l всегда работал…

это я сам не знаю, но надеюсь что libc-2.34.so нету (покрайней мере он не нужен сейчас)

смысл от держания двух файлов?

Так будет как раз два файла, а не один файл и симлинк, как раньше.

в какой версии планируют переписать на Rust?

щас проверю, что будет

Или следуют за сделанным в других ОС – по крайней мере, функционал из libdl в FreeBSD и libdl/libpthread в illumos ((Open)Solaris) давно перенесён в libc.

Glibc тормознее и говнее.

Glibc тормознее

Сравнение от одного из авторов musl, в котором musl сливает glibc по скорости везде, кроме функций, работающих с локалью – в musl настройки локали по большому счету игнорируются, отсюда и опережение.

Locale support is very limited, and barely works

• для Linux добавлена функция execveat
• для Linux добавлена функция close_range

А можно полный список, где используется сабж?

$ls
Mcrt1.o		      libc.so.6		      libnss_compat.so
Scrt1.o		      libc_malloc_debug.so    libnss_compat.so.2
audit		      libc_malloc_debug.so.0  libnss_db.so
crt1.o		      libc_nonshared.a	      libnss_db.so.2
crti.o		      libcrypt.a	      libnss_dns.so.2
crtn.o		      libcrypt.so	      libnss_files.so.2
firmware	      libcrypt.so.1	      libnss_hesiod.so
gconv		      libdl.a		      libnss_hesiod.so.2
gcrt1.o		      libdl.so.2	      libpcprofile.so
getconf		      libg.a		      libpthread.a
ld-linux-x86-64.so.2  libm-2.34.a	      libpthread.so.0
libBrokenLocale.a     libm.a		      libresolv.a
libBrokenLocale.so    libm.so		      libresolv.so
libBrokenLocale.so.1  libm.so.6		      libresolv.so.2
libSegFault.so	      libmcheck.a	      librt.a
libanl.a	      libmemusage.so	      librt.so.1
libanl.so	      libmvec.a		      libthread_db.so
libanl.so.1	      libmvec.so	      libthread_db.so.1
libc.a		      libmvec.so.1	      libutil.a
libc.so		      libnsl.so.1	      libutil.so.1

Собрал, никаких libc-2.34.so более нету

Это разные флаги, один для компилятора, другой для линкера.

alex@ThinkPad-L560:/tmp$ cat main.c 
#include <stdio.h>
#include <pthread.h>

int main(void) {
	return pthread_create(NULL, NULL, NULL, NULL);
}

alex@ThinkPad-L560:/tmp$ gcc -c main.c -o main.o -pthread
main.c: In function ‘main’:
main.c:5:9: warning: null argument where non-null required (argument 1) [-Wnonnull]
  return pthread_create(NULL, NULL, NULL, NULL);
         ^~~~~~~~~~~~~~
main.c:5:9: warning: null argument where non-null required (argument 3) [-Wnonnull]
alex@ThinkPad-L560:/tmp$ gcc main.o -o main.elf
main.o: In function `main':
main.c:(.text+0x19): undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
alex@ThinkPad-L560:/tmp$ gcc --version
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

alex@ThinkPad-L560:/tmp$ ldd --version
ldd (Ubuntu GLIBC 2.27-3ubuntu1.4) 2.27
Copyright (C) 2018 Free Software Foundation, Inc.
Это свободная программа; подробности об условиях распространения
смотрите в исходном тексте.  Мы НЕ предоставляем гарантий; даже гарантий
КОММЕРЧЕСКОЙ ПРИГОДНОСТИ или ПРИГОДНОСТИ ДЛЯ КАКОЙ-ЛИБО ЦЕЛИ.
Авторы программы — Roland McGrath и Ulrich Drepper.

добавлена функция closefrom, которая закрывает все файловые дескрипторы, которые больше или равны заданному значению. Эта функция является расширением GNU;

теперь цикл с закрытием после fork писать не надо?

теперь цикл с закрытием после fork писать не надо?

и статически линковать надо?

glibc статически не линкуется уже давно

Думаю, на современном процессоре с avx memcpy из glibc порвёт, как Тузик грелку, наивную реализацию memcpy из musl, не говоря о всяких других (строковых) операциях.

Ну, вот! Не запустится моя теперешняя программа без цикла после fork на теперешнем debian stable. Придется закопать на пару лет.

Фанатик такой фанатик. Даже на офсайте тесты не посмотрел…

добавлена функция _Fork, async-signal-safe-замена fork.

Это что такое, в обработчике сигналов можно будет форкаться?

Короче, ждём llvm-libc.