Ухухухуху

[metaclass]

"Брось утку в воду и надейся что она поплывет". Действует исключительно на утках, которые инстинктивно знают как плавать, а так же на начинающих линупсоидах, умеющих пользоваться гуглом и man(и то с трудом-с).

Либы поставил в /usr/lib, ldconfig, оказывается, перебивает линки на последнюю текущую версию. Забавная идея, но требует веры в то, что в новых версиях либ бинарный API только расширяется.
Теперь требует libc.so.6 (GLIBC_2.4). Что-то руками ставить оное мне совершенно не хочется, как бы не поломать нахрен полсистемы.

PS: таки чтобы отвязать приложение от новой glibc, нужно пересобрать QT с опцией QT_NO_INOTIFY, и убрать еще там откуда-то опцию stack-protector. Жаль, сейчас нету времени толком разбираться с пересборкой QT и прочей ересью. configure утверждает, что при пересборке make поместит бинарники не туда, куда их поставил инсталлер qtsqk, так что в дебри пока не полезу.

Comments

[inhate.livejournal.com]

Не надо тянуть за сабой саму последнюю версию всего.

Расказы о "тысячах собираемых пакетов" - вранье, по сути требуется сборка под 2 версии libc - ту, которая в текущем RHEL и ту, которая в предыдущем.

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

А вообще - поставляте Xen-образ и все - клиенту совсем не надо знать, что за linux внутри.

[metaclass.livejournal.com]

Последнюю версию glibc за собой тянет сам Qt вроде.

[inhate.livejournal.com]

Вот кстати еще одна проблема пост-вендовая - хвататься за самые распоследние версии библиотек. Оно вам _точно_ надо?
Т.е. есть ли рациональное обоснование использованию Qt 4.5 vs. 4.2 какого-нибудь?

[metaclass.livejournal.com]

Берется, качается qtsqk с сайта троллей, с главной страницы. Ставится. Получаем 4.5.5 qt c зависимостями от glibc_2.4.
Очевидно, что если у меня цель "проверить пригодность этого для продакшена" - надо брать то, что лежит на самом виду, а не начинать заранее разбираться "а не поискать ли нам версию на 3 цифры раньше на всякий случай".

Кстати, из таких вот мелочей и складывается ситуация, что под линукс мы имеем то что имеем - срань господню в плане выбора end-user софта. Я посмотрел бы, в каждой жопе были бы вендоры софта для разработки, если бы у них билд и деплоймент так зависел от произвольных действий гиков над базовыми либами. "А на прошлогодней винде наш софт не работает, потому что мы его скомпилировали на системе с новыми хидерами для kernel32.dll"

[kiryl.livejournal.com]

Посмотри objdump'ом, что именно хочет qt из glibc. Я подозреваю, что простая пересборка qt с более старой glibc поможет.

[inhate.livejournal.com]

Ребе, привыуните к простой мысли: софт на сайте производителя предназначется для создателей дистрибутивов и разработчиков этого софта. Если вы решили поиграться в _ЭТИ_ игры - так надо об этом исказать. Дальше уже можно и форкнуть Qt, и LD_PRELOAD и т.п. - только это уже ни разу не прикладное программирование....
В целом вы гребете портив течения - вместо того, чтобы сделать программу нормальным, совместимым образом - вы пытаетесь сделать свой собственный дистрибутив в дистрибутиве.

[metaclass.livejournal.com]

Софт на сайте производителя предназначен исключительно для тех целей для которых я его использовал - скачать и начать разрабатывать софт с его использованием.
То, что полученный софт при этом не работает на старых дистрибутивах - очевидная недоработка троллей и следствие линуксового зоопарка.
Я то уже знаю, как с этим делом бороться, чтобы оно получилось совместимым, но займусь этим попозже, на сейчас для оценки перспектив мне достаточно. "Могло быть и хуже", ага :)