Собрать curl динамически слинкованный с libcurl.so.4.8.0 вместо libcurl.so.4

Переименуй саму либу, линкуйся с libcurl-my-custom.so.4

это можно, но ведь должен быть нормальный способ

А этот чем ненормальный?

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

Да и все равно вот так с наскоку не выйдет по-твоему: либкурл и сам курл одноременно собирвются и автотулз сам там рулит что с чем линковать – по-твоему выйдет только если свой мейк написат для курла, но там-то я и так могу указать нужную мне версию

Но писать свой мейк – дурь

Во так работает, но это тоже не совсем то, что я искал

$ readelf -d ./curl | grep libcurl
 0x0000000000000001 (NEEDED)             Совм. исп. библиотека: [libcurl.so.4]
$ patchelf --replace-needed libcurl.so.4 libcurl.so.4.8.0 ./curl
$ readelf -d ./curl | grep libcurl
 0x0000000000000001 (NEEDED)             Совм. исп. библиотека: [libcurl.so.4.8.0]

Да и все равно вот так с наскоку не выйдет по-твоему: либкурл и сам курл одноременно собирвются и автотулз сам там рулит что с чем линковать

Ты не поверишь, но команда sed -i может творить чудеса))

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

Уверен? Там много чего могло быть «придумано», чего на практике нет.

Попробуй patchelf --replace-needed

Одновременно)

https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_3.html

-hname
-soname=name
    When creating an ELF shared object, set the internal DT_SONAME field to the specified name. When an executable is linked with a shared object which has a DT_SONAME field, then when the executable is run the dynamic linker will attempt to load the shared object specified by the DT_SONAME field rather than the using the file name given to the linker. 

Тебе надо найти куда вписать -soname=libcurl.so.4.8.0 в сборочные скрипты curl-а.

Ты не поверишь, но команда sed -i может творить чудеса))

Поверю, но для меня снаружи это выглядит как единый мейк. То есть я запускаю сначала configure, потом make (на этом этапе «одновременно» собирается и либа и бинарь) и потом make install.

Можно, конечно, выяснить цель для сборки либы, собрать сначала либу, потом седом подправить что мне там там надо, потом собрать бинарь – можно, не спорю, но я верую в то что должен быть менее наркоманский способ :)

Уверен? Там много чего могло быть «придумано», чего на практике нет.

Конечно, не уверен :) вот и поспрашиваю народ

Тебе надо найти куда вписать -soname=libcurl.so.4.8.0 в сборочные скрипты curl-а.

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

Конечно, не уверен :) вот и поспрашиваю народ

Смотри, как всё это работает при линковке:

1. Программа хочет линковаться с libcurl. Она юзает при вызове линковщика (или gcc) флаг -lcurl.
2. Линковщик находит libcurl.so.
3. Этот libcurl.so на самом деле линк на libcurl.so.4.8.0. Линковщику на это пофиг. Он просто читает этот elf и задаёт вопрос: «какой у тебя soname?»
4. В libcurl.so.4.8.0 указано, что soname у него libcurl.so.4. Именно это является названием данного ABI.
5. Линковщик берёт указанное имя libcurl.so.4 и зашивает его в таблицу needed собираемого бинаря.

Как видишь, места особо разгуляться тут нет. Ты либо меняешь soname в самой либе (можно тем же самым patchelf), либо патчишь бинарь после сборки, как сделал выше.

Почему посреди? Перед сборкой.

Как видишь, места особо разгуляться тут нет. Ты либо меняешь soname в самой либе

А ну как его (soname) можно передать параметром при конфигурации или какой переменной среды?

Ну вообще да, согласен

А ну как его (soname) можно передать параметром при конфигурации или какой переменной среды?

Можно через LD_LIBRARY_PATH указать первой директорию в которой правильный линк libcurl.so.4 на libcurl.so.4.8.0. Но это для конкретного приложения надо делать.

и в скриптах на железяке везеде curl заменить на LD_LIBRARY_PATH=/my/own/lib curl :)

и в скриптах на железяке везеде curl заменить на LD_LIBRARY_PATH=/my/own/lib curl :)

Ну так больше вариантов нету:

1. Смена пути к библиотеке на лету через LD_LIBRARY_PATH.
2. Правка бинарника через patchelf, меняя либо название библиотеки либо можно попробовать свой путь добавить в RPATH.
3. Поправить сборочные скрипты указав -soname.

Ты и бинарь не хочешь трогать, и сборочные скрипты то-же не хочешь менять. И прописывать переменные окружения не хочешь. Как тогда ты хочешь это решить?

А ну как его (soname) можно передать параметром при конфигурации или какой переменной среды?

У меня только так получилось:

sed -i.bak "s/soname_spec='[\$]libname[\$]release[\$]shared_ext[\$]major'/soname_spec='\$libname\$release\$shared_ext\$versuffix'/" configure

уже прям получилось? на курле попробовал?

Да.

Ты и бинарь не хочешь трогать, и сборочные скрипты то-же не хочешь менять. И прописывать переменные окружения не хочешь. Как тогда ты хочешь это решить?

Да все не так радикально, разумеется, я что-то трону :)

Ого, здорово, ща попробую повторить.

Я еще вот что нашел: configure-опцию –with-aix-soname=svr4. Когда у себя добавил – все срослось, собрал и либу и бинарь слинкованными через soname libcurl.so.4.8.0 – вроде-бы бинго, но на другой тачке не воспроизвелось – я в замешательстве пошел дальше разбираться что это за опция

Работает.

Снимаю шляпу.

Через patchelf тоже прокатило, только править пришлось и либу и бинарь