GLIBC: Объясните мне этот ужос

Если glibc просто обновить, то у тебя весь софт, который зависит от glibc поломается.

да, и от глибсов зависит практически все, смена ее версии обычно происходит со сменой мажорной версии дистрибутива

А что делают роллинги в таких случаях? Готовят сразу пачку всего сопутствующего?

пересобрать мир не проблема, десяток пакетов отвалится и не будет работать, но кого это волнует когда ты красноглаз ? через год-два под эту же версию будет собираться уже 98% пакетов, чаще всего это все из-за достаточно простых изменений, которые можно пофиксить самим добавив патчик и не ждать все это время и не терпеть вопросов в духе сабжа

О, вот теперь понятно. То, что я и хотел, собственно услышать и понять. Благодарю.

Если glibc просто обновить, то у тебя весь софт, который зависит от glibc поломается.

Это не правда. В glibc обратная совместимость, софт слинкованный со старой версией glibc всегда будет работать на новой +/- 10 лет наверное.

Но это работает только в одном направлении, откатывать glibc нельзя.

Это правда, ты просто не пробовал. Попробуй любой source-based дистрибутив, увидишь своими глазами.

Лол, я лет 10 сижу на Gentoo, тебе любой гентушник скажет что пересборка мира после обновления glibc не нужна.

Вот тебе небольшой ликбез: https://developers.redhat.com/blog/2019/08/01/how-the-gnu-c-library-handles-backward-compatibility

Ты мне предлагаешь верить рандомному челу(тебе), тогда как я своими глазами видел, что у меня вся система развалилась после обновления glibc? Это шутка такая?

Где в слаке куча патчей ?

0011-clone-internal.c-make-clone3-syscall-optional.patch.gz из одной строки и 3 патча для локали.

В слаке нет проблем с апгрейдом glibc.

Вот даунгрейд - это проблема, но это очень редкий кейс.

Апгрейд glibc редко ломает работоспособность программ.

В glibc заботятся об совместимости с более старыми версиями:

objdump -x /lib64/libc-2.33.so | grep -P '\sGLIBC(..)?_\d+\.\d+(\.\d+)?$'| cut -d' ' -f4 | sed  's/\(.*\)/  \1/' | column -c78
  GLIBC_2.2.5	  GLIBC_2.6	  GLIBC_2.14	  GLIBC_2.25
  GLIBC_2.2.6	  GLIBC_2.7	  GLIBC_2.15	  GLIBC_2.26
  GLIBC_2.3	  GLIBC_2.8	  GLIBC_2.16	  GLIBC_2.27
  GLIBC_2.3.2	  GLIBC_2.9	  GLIBC_2.17	  GLIBC_2.28
  GLIBC_2.3.3	  GLIBC_2.10	  GLIBC_2.18	  GLIBC_2.29
  GLIBC_2.3.4	  GLIBC_2.11	  GLIBC_2.22	  GLIBC_2.30
  GLIBC_2.4	  GLIBC_2.12	  GLIBC_2.23	  GLIBC_2.32
  GLIBC_2.5	  GLIBC_2.13	  GLIBC_2.24	  GLIBC_2.33

Проблема только с параноидальными пакетными менеджерами.

Аргументированно можешь? Развалилась конкретно с какими ошибками?

Ты мне предлагаешь верить рандомному челу(тебе)

Нас, как минимум, двое.

А что делают роллинги в таких случаях?

Ездят с концертами. В любой непонятной ситуации.

Лол, я лет 10 сижу на Gentoo, тебе любой гентушник скажет что пересборка мира после обновления glibc не нужна.

Как любой гентушник говорю - ты гонишь, лучше пересобрать, благо оно редко обновляется

Здесь полазь, увидишь. Как минимум, патчик на 69 Кбайт.

Годный комент. Еще подумал, ответит ли кто-то так или нет.

По ходу, больше всех glibc готовит и прихорашивает дебьян. Жесть, вот это работа у людей и времени куча. А, главное, энтузиазма на это все.

Это было несколько лет назад. Думаешь, я наизусть помню все логи? Ну и шутник. Сейчас могу тебе только показать это. Тоже скорре всего после обновления glibc сломалось

glxinfo: ../nptl/pthread_mutex_lock.c:428: __pthread_mutex_lock_full: Assertion `e != ESRCH || !robust’ failed.

Тема glibc интересна с глобальной точки зрения, в плане, насколько важно иметь всегда свежую версию. Например, glibc 2.36:

… Через madvise() можно информировать ядро об особенностях работы с памятью для оптимизации управления памятью процесса, например, на основе переданной информации ядро может инициировать высвобождение дополнительной свободной памяти.

… функция process_mrelease(), позволяющая ускорить освобождение памяти процесса, завершающего своё выполнение. В обычных условиях освобождение ресурсов и завершение процесса выполняется не мгновенно и по разным причинам может задерживаться, что мешает работе функционирующих в пространстве пользователя систем раннего реагирования на нехватку памяти, таких как oomd (предоставляется в systemd)…

p.s. Многие дистрибутивостроители не обращают внимание на важность обновления glibc. Установлен древний 2.32, да и ладно, никто же не умер… )

Дополню,

$ ldd --version
ldd (GNU libc) 2.36

Хотя еще не обновлял весь арч, и ничего не сломалось. Но наверно у всех по разному и надо аккуратно подходить к такому частичному обновлению.

Если glibc просто обновить, то у тебя весь софт, который зависит от glibc поломается.

Это не правда. В glibc обратная совместимость, софт слинкованный со старой версией glibc всегда будет работать на новой +/- 10 лет наверное.

Ну да, ну да... я бы вам возможно и поверил если бы не начал наступать на эти грабли ещё в прошлом веке.

Подтверждаю. Пересобирать world не нужно. Если у тебя что-то отвалилось, то это частный случай.

Меня тоже можете записать, у меня за 5 лет на генте ничего не отваливалось после обновления глибца

Я сначала пересобирал, но быстро стало лень.

По этой же причине я в итоге ушёл с генты, хэппи энд.

у тебя система развалилась из-за тебя.

glibc обещает обратную совместимость.

Если у тебя не так, то кидай свой баг репорт в их багзиллу.

Если баг репорта ты не покажешь, то ты просто балабол.

Ты в него заглянул?

+++ glibc-20220831_b3736d1a3c/NEWS      2022-08-31 21:08:54.000000000 -0500
@@ -5,6 +5,17 @@
 Please send GNU C library bug reports via <https://sourceware.org/bugzilla/>
 using `glibc' in the "product" field.
 .
+Version 2.36.1
+
+The following bugs are resolved with this release:
+
+  [28846] CMSG_NXTHDR may trigger -Wstrict-overflow warning
+  [29446] _dlopen now ignores dl_caller argument in static mode
+  [29485] Linux: Terminate subprocess on late failure in tst-pidfd
+  [29490] alpha: New __brk_call implementation is broken
+  [29528] elf: Call __libc_early_init for reused namespaces
+  [29539] libc: LD_TRACE_LOADED_OBJECTS changed how vDSO library are
+.

Это все фигня. Вот то, что делает RH с ядрами - вот это лютый звездец. Там версии ядер вообще ничего не значат.

Типа 4.18.0-372.9.1 - это уже совсем не 4.18. Это какой-то мутант! Про ядра 3.10.0-1160 я вообще молчу.

Я обновился glibc и у меня после этого система развалилась и я тут еще и виноват. Ну ты и клоун.

Это просто патч до следующей версии

Ясно.

то, что делает RH с ядрами - вот это лютый звездец

Та да, наслышан.

Ну ты и клоун.

Ты балабол просто, или неосилятор у которого ничего не работает.

Если бы правда что-то разваливалось ты бы обратился к разработчикам и они либо закрыли баг как «Not a bug», и сказали где ты лажаешь, либо бы они починили.

Я пару лет пересобирал, потом забил, так так понял, что это не нужно.

Лол, я лет 10 сижу на Gentoo, тебе любой гентушник скажет что пересборка мира после обновления glibc не нужна.

Подтверждаю. На артиксе (арч-based, тоже роллинг) вроде тоже гладко обновлялось.

А что делают роллинги в таких случаях?

Gentoo без проблем обновляет glibc, не затрагивая остальное. При необходимости какие-то программы могут оставить для себя экземпляр старой версии, но за много лет именно для glibc я этого не видел.

В Gentoo другая проблема с апгрейдом glibc. Даунгрейд штатно невозможен. Только грузиться с флешки и пересобирать мир в чруте под старую glibc. По крайней мере, так было 8 лет назад.

Я обновился glibc и у меня после этого система развалилась и я тут еще и виноват.

Если в команде для обновления сделал столько же опечаток, то да.

Понятно, ну гентушнеги молодцы, чо.

Glibc 2.36 ломает Easy AntiCheat в играх, где он используется. В Arch, чтобы это исправить, накладывают патч. Насчет других других дистрибутивов не знаю.

Если glibc просто обновить, то у тебя весь софт, который зависит от glibc поломается.

Какой-то отдельный софт может отваливаться при обновлении glibc (как например, было с Electron), но весь - точно нет. В Arch Linux glibc всегда обновляется отдельно, без пересборки всех пакетов в репах, и проблем с этим нет. В Void Linux, если не ошибаюсь, glibc тоже обновляется без пересборки всех пакетов.

телеги с Void Linux

Void он с ошмётками системд, про телегу промолчу, но хорошая штука в принципе (наверное даже лучшая для всего).
Посмотри на Obarun и помоги разработчику. Он там почти 1 и всё работает.

с ошмётками системд

Где у него ошметки systemd? Три файла в /lib/systemd/user? Ну ок, пусть лежат. В каких-то пакетах-зависимостях были, вероятно (at-spi-dbus-bus.service, bamfdaemon.service, plasma-xdg-desktop-portal-kde.service). У меня XFCE, если что. Больше в системе ничего нет, ни в /etc, нигде. Ну а к Void Linux я уже привык и уходить не собираюсь. Живет себе второй системой рядом с Debian.

Посмотри на Obarun и помоги разработчику. Он там почти 1 и всё работает.

Я лучше буду там, где есть неплохое коммьюнити и побольше разработчиков, все-таки.