Возможно, это не совсем так, но судя по бинарнику, Qt5Network динамически подгружает любую библиотеку libcrypto, которую найдёт: $ strings /usr/lib64/libQt5Network.so.5.11.1 | grep libssl libssl.* $ strings /usr/lib64/libQt5Network.so.5.11.1 | grep libcrypto libcrypto.* libqt5-network-5.11.1-alt2.S1.x86_64
При запуске программы получаем в консоли qt.network.ssl: QSslSocket: cannot resolve SSLv23_client_method qt.network.ssl: QSslSocket: cannot resolve SSLv2_server_method qt.network.ssl: QSslSocket: cannot resolve SSLv3_server_method qt.network.ssl: QSslSocket: cannot resolve SSLv23_server_method qt.network.ssl: QSslSocket: cannot resolve X509_STORE_CTX_get_chain qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf qt.network.ssl: QSslSocket: cannot resolve SSLeay qt.network.ssl: Incompatible version of OpenSSL
Как вариант: имена файлов подгружаемых библиотек сделаны так, что только у нас такое поведение.
(In reply to comment #2) > Как вариант: имена файлов подгружаемых библиотек сделаны так, что только у нас > такое поведение. Ну, у 1.0 у нас, вроде, было другое название. А у 1.1 у нас такое же как в апстриме. А что там за логика?
Например [zerg@zerg ~]$ rpmvercmp libcrypto.so.10 libcrypto.so.1.1 1 [zerg@zerg ~]$ rpmvercmp libcrypto.so.10 libcrypto.so.1.0.2p 1
[zerg@zerg ~]$ rpmvercmp libcrypto.so.10 libcrypto.so.0 1
(In reply to comment #5) > [zerg@zerg ~]$ rpmvercmp libcrypto.so.10 libcrypto.so.0 > 1 qt использует rpmvercmp для выбора libcrypto?
"Вполне возможно". Надо посмотреть.
(В ответ на комментарий №6) > qt использует rpmvercmp для выбора libcrypto? Видимо, да. Используется функтор LibGreaterThan из http://git.altlinux.org/people/zerg/packages/qt5-base.git?p=qt5-base.git;a=blob;f=src/network/ssl/qsslsocket_openssl_symbols.cpp
(В ответ на комментарий №8) > Используется функтор LibGreaterThan через NumericallyLess в том же файле
А нельзя просто слинковать библиотеку с openssl?
(В ответ на комментарий №10) > А нельзя просто слинковать библиотеку с openssl? Можно, но я уже отказался от этой затеи.
(In reply to comment #11) > (В ответ на комментарий №10) > > А нельзя просто слинковать библиотеку с openssl? > Можно, но я уже отказался от этой затеи. Расскажешь почему?
(В ответ на комментарий №12) > Расскажешь почему? Чтобы зря не пересобирать.
(In reply to comment #13) > (В ответ на комментарий №12) > > Расскажешь почему? > Чтобы зря не пересобирать. Один раз в openssl ABI? Думаешь, отказ от одной пересборки раз в много лет стоит тех проблем, которые мы имеем сейчас?
(В ответ на комментарий №14) > Один раз в openssl ABI? Думаешь, отказ от одной пересборки раз в много лет > стоит тех проблем, которые мы имеем сейчас? Не стоит, конечно. Пересоберите openssl. Достаточно добавить симлинки libcrypto.so.11 -> libcrypto.so.1.1 libcrypto.so.11 -> libcrypto.so.1.1
(В ответ на комментарий №15) > Достаточно добавить симлинки > libcrypto.so.11 -> libcrypto.so.1.1 и libssl.so.11 -> libssl.so.1.1
(In reply to comment #15) > (В ответ на комментарий №14) > > Один раз в openssl ABI? Думаешь, отказ от одной пересборки раз в много лет > > стоит тех проблем, которые мы имеем сейчас? > Не стоит, конечно. Пересоберите openssl. > Достаточно добавить симлинки > libcrypto.so.11 -> libcrypto.so.1.1 > libcrypto.so.11 -> libcrypto.so.1.1 Объясни, пожалуйста, чем этот хак лучше, чем просто честно собрать qt5 с библиотекой, которую он использует? Очевидно, что дополнительная пересборка один раз в новый openssl ABI не может перевесить преимущества линковки.
(В ответ на комментарий №17) > Объясни, пожалуйста, чем этот хак лучше, чем просто честно собрать qt5 с > библиотекой, которую он использует? Потому, что openssl сломал, его и чинить. > Очевидно, что дополнительная пересборка один раз Не один раз, а каждый раз. И у нас не один Qt.
(В ответ на комментарий №18) > (В ответ на комментарий №17) > > Объясни, пожалуйста, чем этот хак лучше, чем просто честно собрать qt5 с > > библиотекой, которую он использует? > Потому, что openssl сломал, его и чинить. > Сергей, но openssl не сломан.
(In reply to comment #18) > (В ответ на комментарий №17) > > Объясни, пожалуйста, чем этот хак лучше, чем просто честно собрать qt5 с > > библиотекой, которую он использует? > Потому, что openssl сломал, его и чинить. > > > Очевидно, что дополнительная пересборка один раз > Не один раз, а каждый раз. И у нас не один Qt.
(In reply to comment #18) > (В ответ на комментарий №17) > > Объясни, пожалуйста, чем этот хак лучше, чем просто честно собрать qt5 с > > библиотекой, которую он использует? > Потому, что openssl сломал, его и чинить. openssl обновился и показал нам багу в qt. > > Очевидно, что дополнительная пересборка один раз > Не один раз, а каждый раз. И у нас не один Qt. Раз в 8 лет? У qt есть зависимости которые обновляются гораздо чаще.
(В ответ на комментарий №21) > openssl обновился и показал нам багу в qt. Если криво обновляться, кого угодно можно сломать. (В ответ на комментарий №19) > Сергей, но openssl не сломан. Это как раз Qt не сломан. Т.к. openssl "починился" с его soname-ом, то ему и разгребать.
Сергей, openssl библиотека более низкого уровня. И мы пересобираем другие пакеты под изменения в ней. Пожалуйста, не надо спорить попусту. Изменения были анонсированы и надо было обсуждать их раньше. А сейчас уже идёт пересборка.
Ладно, давайте спросим мнение главного конструктора.
qt5 в Сизифе собран таким образом, чтобы нельзя было отследить его разлом до того как этот разлом произойдёт. Я считаю, что это ошибка сборки, которую следует исправить. openssl только позволил увидеть эту проблему, в остальном он совершенно не при чём.
Текущая схема ДО СИХ ПОР не ломалась. И я предложил простое решение. В будущем можно его легко выкинуть.
(В ответ на комментарий №23) > Изменения были анонсированы Изменения наименования soname анонсировано не было.
И всё же, почему нельзя просто слинковать qt5 с openssl? Ответь, пожалуйста, на этот вопрос.
qt5 ОБЯЗАНА быть слинкована с теми libcrypto/libssl, которые использует, чтобы все статические проверки ABI, которые у нас реализованы, работали, и пользователи не страдали от таких ошибок, как эта. Сергей, исправь qt5 НЕЗАМЕДЛИТЕЛЬНО!
(В ответ на комментарий №28) > И всё же, почему нельзя просто слинковать qt5 с openssl? Кто сказал "нельзя"? Я считаю более удобным не линковать.
(В ответ на комментарий №29) > qt5 ОБЯЗАНА быть слинкована с теми libcrypto/libssl, которые использует, > чтобы все статические проверки ABI, которые у нас реализованы, работали Ну, хоть аргумент появился. >, и пользователи не страдали от таких ошибок, как эта. От таких больше не будут, только во всех местах, где "не как у всех", вылазили, вылазят и будут вылазить другие. > Сергей, исправь qt5 НЕЗАМЕДЛИТЕЛЬНО! Ok.
http://webery.altlinux.org/task/212070
Сергей, спасибо!
