Стоит ли делать статический glibc?

Просто собери со старым glibc.

А чем он будет отличаться от нового? Старьё будет выдавать ошибки.

Тогда запустится на старых дистрах, и на новых.

[quote] К тому же от статической связки повышается производительность, а не только поддерживаемость. [/quote] А также объём используемой оперативной памяти.

Чем тебя не устраивает системная lIbc?

Тут я не уверен, что программа, собранная на Ubuntu 14.04, заработает например на fedora или новых debian. Там libc вообще другой.

Совместимостью и производительностью.

Вопрос был про статический libc, а не про динамический

Я сказал уже, динамический меня не устраивает

Значит криво написан код, раз ломается на новых libc.

Предоставь исходник и пусть пользователь сам собирает под его систему.

Статический libc потребует больше оперативной памяти.

Мне важна производительность, оперативной памяти тратится не так много. Думаете, что libc сожерёт 2 гига?

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

Мне надо ответ на третий вопрос.

Если там порядок, значит я делаю всё статическим

Я издеваться над пользователями в отличии от многих не хочу, и сделаю всё также как на винде.

На Windows все собирают с динамической libc. Тебя обманули если сказали обратное…

Вот взял для примера первый попавшийся Mozilla Firefox: https://i.imgur.com/8Ku7G3u.png

У меня таких зависимостей вообще нет

Даже если это правда, винда выходит раз в 10 лет, а линуксов довольно много, и то, что моя программа будет запускаться только на единицах, как-то не честно.

В Gentoo есть prelink для ускорения динамического связывания.

https://wiki.gentoo.org/wiki/Prelink/ru

В других Linux тоже есть эта утилита.

В случае сборки тобой статического Libc тебе придётся самостоятельно делать разные сборки под разные libc, потому как новые ядра со старой libc работать не будут, точнее твоё ПО со старой libc не запустится на системах с новыми ядрами.

Так что придётся тебе делать несколько сборок твоего по для таких ядер, для таких ядре и для таких ядер.

Если тебе это удобно - вперёд.

flatpak, snap для тебя.

Кстати, на счёт этого, в винде эта библиотека спокойно распространяется вместе с программой, в linux такое сделать нельзя

Я издеваться над пользователями в отличии от многих не хочу, и сделаю всё также как на винде

Если бы действительно не хотел издеваться, просто выложил бы исходник и всё. Тогда каждый пользователь юзал бы ту версию libc, которая ему нравится.

[quote] винда выходит раз в 10 лет [/quote] Ты ошибаешься, каждое обновление Windows - это новая версия ядра и новые libc, если можно так сказать.

Если говорить о 7 скажем, то каждый новый SP - новоя ядро и новые системные компоненты.

А 10 вообще обновляется раз в не сколько месяцев и ядро и системные компоненты там тоже меняются, от этого у некоторых антиврусных пакетов и драйверов на перефирию, видео карты проблемы возникают.

Думаешь каждый пользователь умеет скачивать пакеты, и компилировать? Это уже точно издевательство.

Я распространяю программу тупой аудитории

Каждый продвинутый пользователь и каждый мейнтейнер. Этого достаточно.

библиотека спокойно распространяется вместе с программой, в linux такое сделать нельзя

Можно, для этого придумали flatpak или можешь использовать LD_PRELOAD и LD_PRELOAD_PATH.

Так зачем её распространять, если она будет конфликтовать с другими системами?

Msvcrt это другое совершенно, работает на любой системе, а libc в linux с ней свазян какими-то модулями, что-то типо такого

Тогда ей нужна версия на линукс только в виде apk :D

Ты про что?

LD_PRELOAD или LD_PRELOAD_PATH ты можешь использовать для указания какие библиотеки нужно подгрузить для конкретной программы.

Напиши скрипт, который будет подставлять в LD_PRELOAD путь до твоих библиотек и далее вызывать твой бинарник.

Если твои библиотеки предоставляют нужные функции, то системные библиотеки использоваться не будут.

Проблему производительности это не решит…

Вот читай это сообщение: Стоит ли делать статический glibc? (комментарий)

Не надо распространять эту программу. Серьёзно.

У него проприетарная поделка, какой код.

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

У меня не бинарник, у меня .so…

Ты понимаешь в чём отличие статически собранной программы от динамически?

Это значит, что если программа собрана статически, то все нужные для её работы функции, даже если они располагались в других библиотеках включены в бинарник этой программы.

И как следствие размер бинарника возрастает, но при запуске этот бинарник уже содержит в себе все нужные ему функции.

В случае динамически собранной программы сам бинарник небольшого размера и при запуске вместе с ним в память подгружаются нужные функции из внешних файлов.

Иногда они подгружаются на лету в момент первого вызова функции.

И уже после первого вызова некоторой функии пока твой бинарник работает код уже ранее вызванной функции находится в памяти.

Поэтому при динамически собранных программах медленным оказывается только первый вызов функции из динамически загружаемой баблиотеки, повторный вызов аналичие вызову функций при статической компоновке приложения.

Ты майнер пишешь?

А .so это не бинарник? :) Её же тоже кто-то подгружает, вот тем кто её подгружает и прописывай LD_PRELOAD и LD_PRELOAD_PATH.

Есть вариант поставить Centos 6, в нём используется glibc 1.12, более старая только в Debian Squeeze.

Если при этом нужен gcc новее 4.4.7, то ставишь в Centos’е devtoolset-7.

Делаю так уже пару лет.

Брат жив.

например на fedora или новых debian. Там libc вообще другой.

Ну-ну! И живут они на другом воображаемом глобусе. Ты о чём, вообще?

Стоит ли делать статический glibc?

не будет работать

сделаю всё также как на винде.

издеваться над пользователями в отличии от многих не хочу

Может тебе не издеваться над пользователями, а ориентиррваться на документированное и стабильное API библиотек и сделать пакеты для нескольких дистров с нормально прописанными зависимостями?

Подумай, нормальные проекты на минимальном финансировании это могут, значит должен суметь и ты.

Если тебе это сложно то просто предоставляй программу в исходниках с раздельными .configure, build и install

П.С. Самые противные и дурацкие проблемы у меня связаны именно с той или иной ‘‘заботой’’ о пользователях.
В общем просто сделай качественный код и оставь пользователям заботится о себе самостоятельно.

О разнице между glibc и eglibc

О разнице между glibc и eglibc

Так о разнице, или о совместимости? И какое тебе дело до разницы?

И о том и о другом

И о том и о другом

То есть ни о чём. Определись!

О совместимости. Где мне компилировать программу, и на какой версии, чтобы она работала и там и там?

чтобы она работала и там и там?

На самой старой доступной тебе glibc. Тогда работать будет везде.

У меня есть только eglibc, а не glibc

У меня есть только eglibc

Ну тогда «тема» ни о чём. У тебя нет вариантов. Статически пришивай свой eglibc и прикрывай шарманку. Весь тред впустую, ничего он для тебя не изменит.

Я задал вопрос в самом начале, будет ли этот статический eglibc работать на других системах

Где мне компилировать программу, и на какой версии, чтобы она работала и там и там?

Для такой фигни есть https://openbuildservice.org/ - делай пакеты под разные дистры

Ну и как вариант, еще можно докерами, снапами и прочим таким бредом обмазаться