Автор Тема: Почему вредно "Истинное ТРУЪ" make install  (Прочитано 14329 раз)

Оффлайн Damir

  • alt linux team
  • ***
  • Сообщений: 134
Где зафиксировано, что в 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. А если собираете - будьте готовы самостоятельно разбираться, что у вас за глюки в системе появились.
Ceterum censeo LORum esse delendam

lx001

  • Гость
Где зафиксировано, что в SONAME пишется  libname.so.${version_major}, и только оно?
Что-то вы ересь какую-то несете, особенно про ${version_major}. SONAME может быть каким угодно,
Наконец-то :)
Цитировать
но основной смысл в том, чтобы динамический линкер ld.so мог вместо имени файла на этапе компиляции использовать более общее имя (SONAME). Указывая полный путь, вы связываете линкеру руки, и вам теперь обязательно придется обеспечивать наличие библиотеки по указанному полному пути.
О чем и речь. :) Библиотека в неправильном месте --> программа не загружается.
Цитировать
Что противоречит идее отладки не от рута.
А зачем вам отлаживаться в / ?
Цитировать
Читайте контекст. Это же вы предлагаете в SONAME полный путь включать.
Посмотрите внимательно, для чего именно. Чтобы однозначно идентифицировать библиотеку, независимо от ее положения.
Цитировать
Цитировать
Как вам поможет -rpath в "-L/libdir/ -Wl,-rpath /libdir -lsmth", если /libdir/libsmth.so указывает на неправильную библиотеку? Опять симлинки будем расставлять?
Если /libdir/libsmth.so указывает на неправильную библиотеку, то в случае вышеприведенной командной строки - вам уже ничего не поможет в любом случае.
Ну наконец-то прорвало :) А тупое /libdir/libsmth.N.x.y.z срабатывает.

Цитировать
Ибо при линковке происходит следующее - из /libdir/libsmth.so достается SONAME, и добавляется в секцию NEEDED.
Опять по кругу.  :) Не указывайте ld libsmth.so.
Цитировать
Правильный способ в данной ситуации - использовать конструкцию /libdir/libsmth.so.N, вместо -L/libdir -lsmth.
Правильно!  :D

Цитировать
Цитировать
Цитировать
а вы видимо путаете симлинк .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 ....
Я так понял,
Нет конечно, вы поняли не так. :)
Симлинки полностью на совести имеющего две версии одного .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
И это тоже вы понимаете, оказывается :) Почему тогда, увидев эту строчку в первый раз, вы посчитали ее кривой?
Цитировать
Видимо кто-то забыл,
Кто?
Цитировать
Вывод из этого такой: тонкостей и подводных камней в таком случае очень много. Никакой автор никаких autotools никогда не сможет предусмотреть их все. И компилируя программу, вы можете получить совсем не то, что хотелось бы.
А теперь исходный вопрос: как RPM spec помогает этого избежать? Вопрос не провокационный на этот раз.

Цитировать
Поэтому, rule of thumb для тех, кто не хочет разбираться в этом геморрое - не собирайте программы в /usr/local. А если собираете - будьте готовы самостоятельно разбираться, что у вас за глюки в системе появились.
Спорное rule of thumb. Безопаснее убрать /usr/local из всех умолчаний, кроме default prefix в autotools.

lx001

  • Гость
P.S.
Чтобы однозначно идентифицировать библиотеку, независимо от ее положения.
И положить ее на правильное место, например, в /pool/jobname/lib/x86_64-slc4-gcc34/, если таскаем ее за job'ом, но это уже grid-специфика.

Оффлайн Astro

  • Участник
  • *
  • Сообщений: 475
  • ALT Workstation 10
делать так систематически и потом не вычищать это дело - и есть превращать свой дистр в слаку.
Согласен, но так или иначе частично в Варю превращается любой дистрибутив, если пользоваться коммерческими закрытыми программами и модулями приложений и сред, которыми майнтейнерам лень собирать.Вот простой пример: для Е17 нужны модули и расширения без которых работать на нём конечно можно, но никто здравомыслящий на голом ёжике работать, понятно, не будет. Соответственно, нужен компилятор, сборка и правка исходников предварительно, и только после получаем какой-то работающий модуль, причём уже установленный, протестированный и благополучно работающий. О нём я итак прекрасно знаю как и где и в чём заключается его работа и что с ним нужно делать, а также прекрасно в курсе какие файлы включает собранный мной модуль. Теперь, потратив как минимум часа три что бы добиться хорошей работы модуля под ALT мне потребуется собрать файлы в пакет, прописать спеки и установить уже установленное, но уже через rpm. Можно, но лениво.
Вообще предполагается что пользователь уже научился хорошо думать и разбираться в своей системе, если он берётся за компилятор и сборку программ или программных компонентов. Иначе так очень недолго привести систему в неработоспособное состояние. Ну а что же касательно коммерческих игрушек, то здесь однозначно домашняя директория для многих из них не очень удачное решение. /opt/games/ как правило проблему решает.

Оффлайн zhe

  • Участник
  • *
  • Сообщений: 88
Согласен, make install - так можно всю систему загадить, а потом и концов не найдёшь.
ещё ничего, если Makefile сделан с целью uninstall - что не часто увидишь, а если нет, то систему крайне сложно вычищать..
rpm-based - значит, rpm-based, что тут мудрить - рмп не так уж и сложно собрать и spec не сложнее, а гораздо легче, чем Makefile ..
man google.com

Оффлайн black_13

  • Участник
  • *
  • Сообщений: 657
  • Gentoo + Debian + ALT
    • diff.org.ua
А ko-шки ядру тоже левые скармливать нельзя?  :'(

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 20 171
    • Домашняя страница
А ko-шки ядру тоже левые скармливать нельзя?  :'(
Попробовать можно, но они гарантированно не встанут. ;)
Андрей Черепанов (cas@)