После шести месяцев разработки опубликован релиз системной библиотеки GNU C Library (glibc) 2.34, которая полностью следует требованиям стандартов ISO C11 и POSIX.1-2017. В состав нового выпуска включены исправления от 66 разработчиков...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=55575
Круто, спасибо! Пойду обновляться =)
> Прекращено использование символических ссылок для привязки устанавливаемых разделяемых объектов к версии Glibc. Подобные объекты теперь устанавливаются как есть (например, libc.so.6 теперь является файлом, а не ссылкой на libc-2.34.so).То есть libc-2.34.so существовать не будет?
Т.е. ты так просто хотел отменить депенденси хел в Линуксе? Смешной, это же опенсорсная скрепа.
Soname было и будет libc.so.6. Именно так записано в бинарнике, именно это ищет динамический компоновщик. Ссылка это или файл - не важно.
Soname было и будет libc.so.6. Именно так записано в бинарнике, именно это ищет динамический компоновщик. Ссылка это или файл - не важно.
А если есть софт который уже скомпилирован и он зависит от другой версии glibc. И ссылается он на этот же lib.so.6, который другой версии. Можно было с самого начала ссылаться на конкретную версию.И решительно непонятно почему самый юзабельный способ это обойти это какие-то мутные контейнеры. И поди еще выбери флатпак, снап или аппимадж.
> А если есть софт который уже скомпилирован и он зависит от другой
> версии glibc.Если от более новой -- то как бы Вы это предложили делать ещё? soname bump потянет конфликты с первой же попавшейся другой библиотекой, скомпонованной с другой glibc.
Хорош уже в голову есть токмо, матчасть учите или хотя бы _попытайтесь_ применить раз в жизни голову по назначению.
PS: конфликты по символам, уточню сразу для альтернативно одарённого.
Есть такое понятие - обратная совместимость. А применительно к разделяемым библиотекам есть ещё и версионирование символов.
Нет никаких разделяемых библитотек -- есть совеместно используемые (общие) библиотеки и объекты. Разделяемым бывает косячок, ужин, т.е. то, что расходуется и это можно разделить на части. Остальное "shared" -- это совместно используемое.
> Разделяемым бывает [...] то, что расходуется и это можно разделить на части.Это вы откуда взяли?
Есть устоявшаяся терминология, и термин "shared library" переводится как "разделяемая библиотека".
>Есть устоявшаяся терминология, и термин "shared library" переводится как "разделяемая библиотека"Это неправильный перевод!
Разделяемое это когда Divide & Conquer - Разделяй и Покоряй или Divide & Rule - разделяй и властвуй.
Shared - это переводится как общеее или библиотека для общего использования.
В русском языке нет точного перевода с сохранением части речи - adverb/наречия.Более корректно, но длинно - "переданное в общее использование".
Этот софт будет работать через новую версию.
Вот с такими идеями и получается "депенденси хелл". Плюс необходимость иметь для каждой версии glibc симлинки на последнюю
Шёл 2021, вендузяторы продолжали пытаться натянуть свою адскую сову на чужой глобус.
Вы так говорите "натянуть адскую сову на чужой глобус", как будто это что-то плохое.
...притом, как обычно, бездарно и безграмотно: у glibc всё _очень_ хорошо с версионированием символов и, как следствие, с обратной совместимостью.А вменяемым людям можно посоветовать DSO HOWTO во избежание типовых ошибок: http://akkadia.org/drepper/dsohowto.pdf
PS: и да, скрепа. Пусть завидуют -- у них-то сопли и скотч.
Даже в этой теме есть независимые свидетели у которых все плохо с совместимостью https://www.opennet.dev/openforum/vsluhforumID3/124945.html#26 но тут продолжаются сказки про совместимость. Она конечно может иногда и есть, а иногда нет. А хотелось бы методику чтобы совместимость была всегда.
Пук в теме не подкрепленный ни одним пруфом - это свидетельство? Я вас разочарую.
проверил, не будет
Единственная нормальная библиотека.
Знаешь, я прочитав и покопавшись в вики так и не понял для чего она.
*Здесь идёт шутка про книжную библиотеку*
очевидно.
для чтения. даже библиотекарь может только собрять.
Чтобы транслировать Си-шный код, очевидно же.
libc нужна не для того, чтобы не транслировать, а чтобы собрать оттранслированное в исполняемый модуль. Трансляция с языка Си не требует наличия libc в системе, в том числе и libc -- достаточно компилятора.
> В основной состав libc интегрированы библиотеки libpthread, libdl, libutil и libanlХоба! Привет Солярису.
Кстати, теперь в ближайшее несколько лет autotools актуальны как никогда 😏
> Кстати, теперь в ближайшее несколько лет autotools актуальны как никогда 😏Почему?
А мне вот интересно: "-lpthread" при линковке сломается сразу (раз нету такой библиотеки)?
Всё-таки, posix-треды — инструмент довольно популярный и используется в массе наколеночных поделок (в т.ч. и моих).
Придётся держать в голове очередной "нюанс". При том что "выстрелит" он в проде через N лет.
они делают пустышки, что б линкер не ругался.
Есть в оригинальном анонсе."For backwards compatibility,
empty static archives libpthread.a, libdl.a, libutil.a, libanl.a are
provided, so that the linker options keep working."
Я не проверял, но такие пустышки в Солярке были настоящим кошмаром, называемым filter library. Они реально содержали все символы правильных версий (без кода, конечно), а динамический компоновщик "перенаправлял запрос" в libc. И иногда связывание с libc и lpthread одновременно приводило к феекрическим ошибкам.
- Видишь феерические ошибки?
- нет
- и я тоже не вижу. А они есть.
> Прекращено использование символических ссылок для привязки устанавливаемых разделяемых объектов к версии Glibc. Подобные объекты теперь устанавливаются как есть (например, libc.so.6 теперь является файлом, а не ссылкой на libc-2.34.so).Хоба! Привет Солярису.
> интегрированы библиотеки libpthread, libdl, libutil и libanl,С одной стороны, исчезнут баги когда при сборке не добавилось -lpthread или еще что нибудь, с другой libc.so.6 станет более жирной, что может увеличить расход ОЗУ и время запуска слинкованных с ней программ, однако т.к. вес этих либ в сумме около 200кб это все будет очень не значительно, поэтому если не сломает совместимость - я за
Ничего не изменится. Разделяемые библиотеки на то и разделяемые, а статическое связывание включает только необходимый минимум - в глибси практически каждая функция в отдельном файле.
> Ничего не изменится. Разделяемые библиотеки на то и разделяемые, а статическое связывание
> включает только необходимый минимум - в глибси практически каждая функция в
> отдельном файле.так если их совместили - в динамическую библиотеку добавился функционал других => вырос ее размер. Однако т.к. все эти либы очень маленькие а libc.so большая - это все на грани погрешности
По сравнению с компиляцией всей glibc из исходников это время минимально.
> По сравнению с компиляцией всей glibc из исходников это время минимально.какое время?
В LFS сборка за два захода занимает никак не меньше 2-х часов.
> В LFS сборка за два захода занимает никак не меньше 2-х часов.зависит от железа. у меня около 5 минут одна сборка (-j9 без тестов)
Там что-то не то, вот на 12 летней затычке от интела в 4 потока2019-11-28T15:00:54 >>> sys-libs/glibc: 8′39″
2019-12-11T18:04:14 >>> sys-libs/glibc: 9′10″
2020-02-22T01:21:48 >>> sys-libs/glibc: 13′57″
2020-03-13T08:17:20 >>> sys-libs/glibc: 9′04″
2020-04-29T22:02:47 >>> sys-libs/glibc: 13′52″
2020-05-19T00:54:06 >>> sys-libs/glibc: 9′51″
2020-06-02T10:03:09 >>> sys-libs/glibc: 8′42″
2020-06-29T05:06:43 >>> sys-libs/glibc: 9′21″
2020-07-27T18:57:03 >>> sys-libs/glibc: 12′26″
2020-08-15T09:12:55 >>> sys-libs/glibc: 19′37″
2020-10-01T04:43:24 >>> sys-libs/glibc: 11′17″
2020-11-11T12:09:38 >>> sys-libs/glibc: 10′52″
2020-12-08T06:49:08 >>> sys-libs/glibc: 11′04″
2020-12-18T11:37:10 >>> sys-libs/glibc: 9′27″
2020-12-24T17:44:44 >>> sys-libs/glibc: 10′22″
2021-01-07T16:19:14 >>> sys-libs/glibc: 10′52″
2021-06-14T09:45:21 >>> sys-libs/glibc: 9′45″
2021-07-16T21:06:33 >>> sys-libs/glibc: 10′49″
2021-07-18T06:19:53 >>> sys-libs/glibc: 12′01″
2021-07-27T16:33:22 >>> sys-libs/glibc: 12′34″
2021-07-28T15:11:02 >>> sys-libs/glibc: 12′08″
За 3 года в 5 раз больше обновлений glibc, чем было за 5 лет до того. Ну и в 16 году было 4 минуты, в 17 4 с половиной, в 18 уже 5 и в 19 стало 9. Стало ли работать быстрее? Да не особо, только замедления видно.
время сборки я субьективное сказал, исходя из sbu должно быть ~2 минуты. Однако причем тут время сборки я так и не понял
Замедление работы glibc из-за увеличения её размеры ничтожны по сравнению с тем сколько она компилируется в том числе с новым функциями, которые увеличат время компиляции.
При всем желании glibc никак не попадает в рейтинг монстров по продолжительности компиляции.
Там соооовсем другие герои.Тут явно есть какая-то путаница.
>> Ничего не изменится. Разделяемые библиотеки на то и разделяемые, а статическое связывание
>> включает только необходимый минимум - в глибси практически каждая функция в
>> отдельном файле.
> так если их совместили - в динамическую библиотеку добавился функционал других =>
> вырос ее размер. Однако т.к. все эти либы очень маленькие а
> libc.so большая - это все на грани погрешностиЭти либы и так почти везде прилинкованы, так что суммарный размер станет наоборот чуть меньше.
> Эти либы и так почти везде прилинкованы, так что суммарный размер станет
> наоборот чуть меньше.Ну вообще то обычно только одна-две из них
А что такое libanal, что-то вроде libcares? Libutil тоже неясно зачем надо. Libdl довольно специфичное как по мне, а libpthread в чисто однопоточном приложении кмк не упало (да и там были какие-то альтернативные реализации). Это лишнее наверно.
Статически слинкованный хелловорд у glibc 800кб, у musl не то в 10, не то в 30 раз меньше. На самом деле, может, даже и уменьшатся файлы, ну, там, на 1кб, может.
> Статически слинкованный хелловорд у glibc 800кб, у musl не то в 10,
> не то в 30 раз меньше. На самом деле, может, даже
> и уменьшатся файлы, ну, там, на 1кб, может.про статическую линковку я не говорю, .a это архив с обьектниками, линкуются только нужные
P.S. со strip -s статически слинкованный 770 кб (-O2)
У меня большой сишник в 9000 строк через libc 87k, через musl - 85k. При этом musl работает на 8% медленнее.
> Объявлены устаревшими функции pthread_mutex_consistent_np, thread_mutexattr_getrobust_np, pthread_mutexattr_setrobust_np и pthread_yield вместо которых следует использовать pthread_mutex_consistent, thread_mutexattr_getrobust, hread_mutexattr_setrobust и sched_yield.Просто праздник какой-то!
*_np - это non portable, то есть не нужно.
К сожалению, переносимость работает только там, где поддерживается посикс. У микрософта до сих даже 9899-1999 не поддерживается -- приходится кросскомпилировать в linux mingw (виндовый mingw неработоспособен).
> Для обеспечения обратной совместимости с приложениями, собранными со старыми версиями glibc, предоставлены библиотеки-заглушки.Всегда было не совместимо. Сколько не подсовывай, не переименовывай с новой биб-кой старые и не очень старые проги не пускалиль или падали.
Этот момент надо как то специально в glibc прорабатывать, возможно даже на уровне, не побоюсь этого слова, дядьки Столмана.
А сколько лет там совместимость? Последние лет 8 точно есть (я достаточно успешно использовал пакеты собранные для 2012 убунты в генту с год назад), но для софта 2000 года приходится тащить glibc из debian 3, там с sdl какие-то проблемы может и из-за glibc.
Это конечно все хорошо, но зачем ты это делаешь?
Иногда надо запускать проприетарный софт.
Проприетарный софт идет со своими версиями библиотек и я со времен Red Hat 6.0 не помню случая, когда бы он не работал или как-то глючил. Просто нужно перед установкой читать документацию и следовать ей буквально. Мой список бепроблемной установки и работы в течение более 20-и лит:
- любой софт mentor graphics;
- maple;
- matlab;
- slickedit.
Замечено, что любой софт, официально устанавливаемый на RHEL или SUSE работает под любым линуксом, который использует rpm и не поддерживает deb. Ну а разного рода версии убунты и прочие deb-дистры -- это проблемы не линукса, а дистроизобретателей.
DeaDBeeF, например, static-builds собирается в окружении Ubuntu 14.04 (2014г.) и ничего - вполне себе нормально работает на любых современных linux ( https://imgur.com/U1NZwqD )
Самое то для для прослушивания вирусов в mp3. Какой тут смысл не собирать статически в убунту-9999?
> Самое то для для прослушивания вирусов в mp3.Можно мысль развернуть?
> Какой тут смысл не собирать статически в убунту-9999?Хочешь - пересобирай, ничего сложного, все собирается. Автору не упёрлось собирать под каждый конкретный дистр и репы, поэтому он собирает static-builds с минимально возможной версией библиотек имеющих стабильный API (к которым и glibc тоже относится). Кто хочет собирать в репы арч/генту/ещё где-то - автор, насколько я в курсе, не возражает. Против самостоятельной сборки хоть с самым распоследним окружением тоже никто не возражает.
Но ведь статические билды ни от чего не зависят кроме себя. Логично было бы выбрать всё самое актуальное и исправленное на момент сборки. Про вирусы это про множественные уязвимости с исполнением кода в медиа либах. Если специально подготовленный файл содержит вирусный код, плеер его выполнит.
> Но ведь статические билды ни от чего не зависят кроме себя.Они зависят от рантайма. Статические билды не тащат за собой glibc и остальное.
Собствено
ldd /opt/deadbeef/bin/deadbeef
linux-vdso.so.1 (0x00007fff43df7000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1e49fd6000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1e49e88000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1e49e66000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e49c7a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1e49ffa000)
Это не то чтобы статический билд. Ну так смысл тогда в новой glibc, если остальные либы старьё? Можно было бы собирать с самым свежим и всё, раз уж всё равно куча бандленного дерьма идёт.
> Это не то чтобы статический билд.А какой-же тогда. Берёшь распаковываешь из архива, запускаешь бинарник - всё работает.
> Ну так смысл тогда в новой glibc, если остальные либы старьё?
glibc линкуется с приложением не статически. Но у glibc стабильный API/ABI, поэтому ты можешь запустить в системе с новым glibc приложение собранное со старым без перекомпиляции (обратное не гарантируется), т.к. с точки зрения приложения ничего не поменялось (с gtk3 > 3.10 в общем-то также, я собирал для DDB, в котором gtk3-плагин cобран с gtk-3.10, плагин с gtk 3.36 и ничего - всё нормально работает).
> Можно было бы собирать с самым свежим и всё, раз уж всё равно куча бандленного дерьма идёт.
Собери, никто не против, код открыт (собирается, я пробовал). А автору хочется чтобы его единственный билд (за который он отвечает) работал как-минимум на всех поддерживаемых LTS.
> А какой-же тогда. Берёшь распаковываешь из архива, запускаешь бинарник - всё работает.Это динамический билд.
> libc линкуется с приложением не статически. Но у libc стабильный API/ABI, поэтому
> ты можешь запустить в системе с новым libc приложение собранное соЭто всё лишено смысла, когда бандленный шлак и остальные либы из 1000 раз протухшего дистрибутива.
> Собери, никто не против, код открыт (собирается, я пробовал). А автору хочется
Денег и не интересно делать нормально, жрите, что дают.
> Это динамический билд.
> Это всё лишено смысла, когда бандленный шлак и остальные либы из 1000 раз протухшего дистрибутива.facepalm.
> Денег и не интересно делать нормально, жрите, что дают.
Именно поэтому он распространяет его бесплатно в бинарниках и сорцах по Zlib и делает сборки под linux даже семилетней давности (там группа заинтересованных ещё и под Win сборку сделали), хотя сам сто лет как Мак юзает (и тамже его собирает из техже сорцов)?
Это всё от недостаточной квалификации, иных объяснений зачем так делать у меня нет.
> Это всё от недостаточной квалификации, иных объяснений зачем так делать у меня нет.Или от того, что кому-то не хочется сношаться под правила и набор пакетов ~100500 дистрибутивов, про что waker много раз говорил.
Насколько я знаю, он пытался этим занятся, после примерно 100500 требований и корёжений проекта под каждый новый вывих мозга мейнтейнеров дистров он на это дело плюнул - кто хочет пусть тот и мейнтейнит.
Иконка виндоуз вместо кнопку Пуск красочно описывает человека, который вместо пересобирания всего из исходников шаманить с библиотеками скомпилированных блобов.
> Иконка виндоуз вместо кнопку Пуск красочно описывает человека, который вместо пересобирания всего из исходников шаманить с библиотеками скомпилированных блобов.Ты третьегном не узнал чтоли?
Подсказываю №1, в ArcMenu можно ставить какую хочешь.
Подсказываю №2, скриншот с моего ноута и пользуюсь им в семье не только я.И да, с возрастом радость сношаться со сборкой всего и вся проходит.
Это не к тому что на скрине оффтопик. Это к тому что аффтор хочет сделать из третьегнома оффтопик. И соответствующие работает с софтом, нелинуксвейно так сказать.
> Это не к тому что на скрине оффтопик. Это к тому что аффтор хочет сделать из третьегнома оффтопик.На вкус и цвет фломастеры разные.
> И соответствующие работает с софтом, нелинуксвейно так сказать
Судя по том бреду, что выше написал Аноним, пользование какого-нибудь i3w ему не сильно помогает.
> требуется наличие устройства /dev/shm/dev/shm вроде же раньше было каталогом
Вот век учись — дураком помрёшь.
Никогда не думал что глючный nscd собирается как часть glibc.
Ну хоть ставится этот уродец (являющийся поставщиком трудно диагностируемых проблем в системе) отдельным пакетом.* Чего я на него взъелся: оно встраивается в систему аналогично вирусам/"антивирусам" и производит набор эффектов, достойных легендарного "Касперского".
Его можно спокойно выпилить. Он устарел. У меня он лично даже не собирается и полностью выпилил его, в Arch Linux он неактивен, хоть устанавливается, а в Федоре есть план по выпиливанию, вроде в 35 федоре его полностью выпилят https://fedoraproject.org/wiki/Changes/RemoveNSCD
>mtrace(), mcheck(), shm_open, sem_openу сишников приняты такие тупые названия, немудрено что они в них путаются и рожают баги )
Хотел запрограммировать кофеварку на Джава, как обещали когда-то, но на перфокарту не влезли имена.
Koookkkkooookoooooo JavaME тебе в помощь
Там тоже mcheck() и подобные имена?
Просто в твой микроум не влезает ничего кроме Hello World!
> Для платформы Linux реализована функция
> Для платформы Linux реализован параметр
> В Linux для работы функцийКак будто кроме "платформы Linux" (и виртуального Hurd) еще куча платформ поддерживается.
Есть мнение что представители других платформ не внесли никакого вклада в glibc в этом релизе.
> Есть мнение что представители других платформ не внесли никакого вклада в glibc в этом релизе.Есть мнение, что оно нигде больше и не рабоатет, что впрочем "воркс ас интендед".
> POSIX.1-2017А он бесплатно анону доступен или только за деньгу?
Незнаю.
Если смотреть на сайте https://www.ieee.org то за IEEE 1003.1-2017 в формате PDF хотят 856$По этому GNU/Linux и *BSD дистрибутивы этот стандарт не поддерживают.
Нет. Лиуксоиды отыскивают черновые варианты стандартов и по ним делают свою GNU/Linux. Не платят из принципиальных соображений, потому-что стандартизаторы будут требовать денежных отчислений с каждого дистрибутива GNU/Linux.
Single UNIX Specification 4, Unix Base Specifications, Issue 7, 2018 Edition
html-версия доступна анону, но зачем..
Можешь бесплатно его получить на сайте opengroup.org как Single UNIX Specification(SUS) это тот же POSIX местами расширенный и бесплатный
- В основной состав libc интегрированы библиотеки libpthread, libdl, libutil и libanlНу накотец-то.
Кто уже поборол баги хрома и лисы, что с новым glibc они крешатся при включеном sandbox? У кого при запуске крешится хром, его можно запустить с отключенной песочницей chromium --no-sandbox
Хром? А зачем тебе следилка Гугла? Анальных зондов тебе не хватает?
Хочет большего расширения.
Переписать на rust и закопать.