python 3.4 - 3.5, да на компе с libc 2.5

Будь мужиком, собери себе нового питона статически с musl libc. На Alpine например.

Поможет ли мне статическая линковка libc

Нет, влинковывание конкретно glibc ничего кроме проблем не принесет. Не делай этого. http://micro.nicholaswilson.me.uk/post/31855915892/rules-of-static-linking-li...

Самый древний из линуксов: linux 2.6.18, libc 2.5, gcc 4.1.2.

Я собирал gcc 4.8.4 на rhel 4.8. Это glibc 2.3.4 и ядро 2.6.9 . Собралось и заработало. Единственный нюанс был в том, что нужно было брать binutils-2.21.1 , с более свежими не собиралось.

влинковывание конкретно glibc ничего кроме проблем не принесет. [и далее по ссылке libc ест детей]

Это похоже на новости из glibc-only манямирка. Чем плохо статически musl влинковать? На RHEL5 результат заводится на ура, вероятно и на Lenny заведется.

Чем плохо статически musl влинковать?

1. Тем, что libc в зависимости от версии ядра может (и должен) быть устроен по-разному.

2. «musl libc does not even implement dlopen() for statically linked programs, since it imposes a number of serious problems»

Пример конкретный можно, что должно быть по разному в libc (для ядер 2.6.18+)? API ядра твердокаменный же.

Не являюсь специалистом ни в ядрах ни в libc, но собранный в Alpine (запущенном в докере) небольшой проект, где используются треды, select/poll и vfork/exec собрался ок вот с такими флагами g++ (4.9):

-static -static-libgcc -static-libstdc++ -pthread

И вот с такими, (подобранными пока не заработает pthread, в новом альпине починили возможно) флагами линковки:

-u pthread_create -u pthread_once -u pthread_mutex_lock -u pthread_mutex_unlock -u pthread_join -u pthread_equal -u pthread_detach -u pthread_cond_wait -u pthread_cond_signal -u pthread_cond_destroy -u pthread_cond_broadcast -u pthread_cancel

В результате получается статический бинарник, как от golang, только в отличие от go он работает на RHEL 5.

Написал до того, как увидел исправление с п. 2. dlopen() не использую, но для тех кому он нужен - это валидный аргумент в сторону glibc.

а он мне скажет kernel too old, ага

ребят, есть на мой случай какая-нибудь общая и непоколебимая истина, кроме «компиляй на некроте»? я много что могу, хоть в user mode linux завернуть и распространять. а хочу сделать просто и правильно, чтобы мой преемник пожал плечами и сказал «а как иначе?», а не мечтал набить мне морду.

а он мне скажет kernel too old, ага

Ведро старше чем в RHEL 5? Да ладно, такое бывает? А кто его поддерживает? Или это какой-то суровый ембеддед со своим тулчейном?

user mode linux завернуть и распространять

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

Пример конкретный можно, что должно быть по разному в libc (для ядер 2.6.18+)? API ядра твердокаменный же.

Вот тебе первый попавшийся пример (по идее, таких примеров должно быть много, но мне скучно в этом копаться, так что развивать тему дальше я не буду):

http://man7.org/linux/man-pages/man2/fallocate.2.html

This is a nonportable, Linux-specific system call. For the portable,
POSIX.1-specified method of ensuring that space is allocated for a
file, see posix_fallocate(3).

fallocate() is available on Linux since kernel 2.6.23.

http://man7.org/linux/man-pages/man3/posix_fallocate.3.html

posix_fallocate() is available since glibc 2.1.94.


In the glibc implementation, posix_fallocate() is implemented using
the fallocate(2) system call, which is MT-safe. If the underlying
filesystem does not support fallocate(2), then the operation is
emulated with the following caveats:

* The emulation is inefficient.

* There is a race condition where concurrent writes from another
thread or process could be overwritten with null bytes.

* There is a race condition where concurrent file size increases by
another thread or process could result in a file whose size is
smaller than expected.

* If fd has been opened with the O_APPEND or O_WRONLY flags, the
function will fail with the error EBADF.

это максимально ректальное, что я придумал. можно минимально ректальное?

М, мне кажется уровень ректальности неверно оценен. Я слышал что красношапка (которая вцелом отличается консервативностью) сейчас для всех приложений в своих энтерпрайзных Software Collections требует поддержку завертываемости в Докер из коробки (иначе не пускаеют приложения в SCL).

а он мне скажет kernel too old, ага

Там при сборке есть опция --enable-kernel=версия, которая, по идее, должна включать всё, что нужно для указанной версии ядра и новее.

Ещё можно попробовать взять LSB SDK (самый новый), посмотреть, какую версию LSB потянут твои дистрибутивы, и собирать под неё.

Мой опыт некрофилии подсказывает, что проще всё-таки собрать. У Python достаточно низкий порог минимальных требований. ЕМНИП, Python 3.4 успешно собрался на ванильном rh 9 (это 2003 год).

Поддерживаю, Python хорошо собирается, особенно если Tk GUI не включать в соборку. Собирал 2.6 под оффтопик несколько лет назад.

Спасибо.