Где зафиксировано, что в SONAME пишется libname.so.${version_major}, и только оно?
Что-то вы ересь какую-то несете, особенно про ${version_major}. SONAME может быть каким угодно, но основной смысл в том, чтобы динамический линкер ld.so мог вместо имени файла на этапе компиляции использовать более общее имя (SONAME). Указывая полный путь, вы связываете линкеру руки, и вам теперь обязательно придется обеспечивать наличие библиотеки по указанному полному пути. Что противоречит идее отладки не от рута.
В то же время нормальный SONAME и RPATH/LD_LIBRARY_PATH/etc/ld.so.conf позволяют более гибко указывать местоположение библиотеки.
Причем _здесь_ SONAME?
Читайте контекст. Это же вы предлагаете в SONAME полный путь включать.
Как вам поможет -rpath в "-L/libdir/ -Wl,-rpath /libdir -lsmth", если /libdir/libsmth.so указывает на неправильную библиотеку? Опять симлинки будем расставлять?
Если /libdir/libsmth.so указывает на неправильную библиотеку, то в случае вышеприведенной командной строки - вам уже ничего не поможет в любом случае. Ибо при линковке происходит следующее - из /libdir/libsmth.so достается SONAME, и добавляется в секцию NEEDED.
Правильный способ в данной ситуации - использовать конструкцию /libdir/libsmth.so.N, вместо -L/libdir -lsmth.
Дети - не делайте как lx001, не занимайтесь нецелевым использованием фич компоновщика (linker abuse)!
а вы видимо путаете симлинк .so -> .so.N с SONAME.
Где это вам увиделось? :)
Да везде. Что ни вопрос про SONAME - сразу упоминаете симлинк.
Автотулз как раз и сделаны в таком виде, чтобы автор не думал о портабельности.
_Должны_ быть сделаны. :)
Не плодите велосипедов сверх меры - используйте стандартные способы линковки.
В таких случаях делается, например,
( mkdir -p .include/ && cd .include/ && ln -s /usr/include/A.h . && ln -s /usr/local/include/B.h . )
gcc -I ./.include ....
Я так понял, вы предлагаете всю эту ерунду производить автору configure.ac/Makefile.am??? Да вы в своем уме? Я уж не говорю про то, что A.h может включать A1.h, а тот в свою очередь B1.h и т.п.
Как правильно после этого запустить ld с libA.so.N и libB.so.M, видимо, сами знаете, если в /usr/lib:
libA.so -> libA.so.N
libA.so.N -> libA.so.N.x
libB.so -> libB.so.N
libB.so.N -> libB.so.N.y
Эти симлинки не имеют особого отношения к делу. libB.so может указывать сразу на libB.so.N.y. Промежуточный libB.so.N нужен лишь потому, что у библиотеки libB.so.N.y прописан SONAME libB.so.N, и использоваться файл libB.so.N будет только в случае запуска программы, слинкованной с libB.so.
Следующий правильный вопрос такой:
что делать, если в /libdir/ есть libA.so.N и libA.so.M, и libA.so -> libA.so.M, а нам нужна именно libA.so.N?
-Wl,-rpath /libdir /libdir/libA.so.N
Видимо кто-то забыл, что на самом деле конструкция -L/libdir -lsmth - это аналог /libdir/libsmth.so в строке линковщика. Так сказать, shortcut. Который ищет libsmth.{so,a} в указанных каталогах (а команда -L добавляет каталог к списку поиска). Вместо поиска можно использовать прямое указание файла. Тонкости в виде скриптов линкера пока оставим в стороне.
Вывод из этого такой: тонкостей и подводных камней в таком случае очень много. Никакой автор никаких autotools никогда не сможет предусмотреть их все. И компилируя программу, вы можете получить совсем не то, что хотелось бы.
Поэтому, rule of thumb для тех, кто не хочет разбираться в этом геморрое - не собирайте программы в /usr/local. А если собираете - будьте готовы самостоятельно разбираться, что у вас за глюки в системе появились.