Статическая линковка с помощью libtool без изменения dependency_libs в файле .la

В проекте, основанном на autotools, я собираю еще одну небольшую статическую библиотеку и связываю ее с моей окончательной общей библиотекой безопасным способом (статика создается с помощью -fPIC и т. д.). В конце концов, не должно быть никаких доказательств того, что существование внутренней статической библиотеки как части процесса сборки, и все ее символы должны быть «скопированы» в общую библиотеку.

Последнее условие, безусловно, выполнено, проверено с помощью nm, и использование ldd в общей библиотеке не обнаруживает «необходимой» зависимости раздела ELF от статической библиотеки. Но архивный файл libtool .la — это совсем другая история: переменная dependency_libs в нем содержит запись -lmy-secret-temp-lib (имена были изменены для защиты невиновных), которая затем ломает любой основанный на libtool проект, который пытается собрать окончательную библиотеку, поскольку эта зависимость может никогда не встретить. Проекты без libtool, конечно, хороши, поскольку ничто, кроме libtool, не просматривает .la файлов.

Есть ли способ, которым я могу указать libtool не добавлять библиотеку в переменную dependency_libs в своем файле .la, когда она включена в переменную xxxx_la_LIBADD? Может быть, есть какие-то аргументы до и после, такие как -flibtool_ignore -lmy-secret-lib -flibtool_payattention, чтобы позволить разработчику сказать libtool, чтобы он перестал мешать? Было бы неплохо иметь возможность указать autotools/libtool вообще не создавать/устанавливать файл .la, но это не вариант!


person andybuckley    schedule 28.01.2014    source источник
comment
Вы можете изучить удобные библиотеки libtool так как это звучит очень похоже на то, что вы сейчас делаете.   -  person ldav1s    schedule 28.01.2014
comment
@ldav1s Спасибо за предложение, но я уже знаю об удобных библиотеках - по сути, я хочу использовать статическую библиотеку, не относящуюся к libtool, в качестве удобной библиотеки, но не могу найти способ сделать это...   -  person andybuckley    schedule 28.01.2014


Ответы (1)


Вот лучшее решение, которое мы нашли для потомков:

Кажется, нет очень аккуратного способа заставить это работать. Лучшее, что я нашел, это избегать флагов -L и -l при "внутренней" компоновке, а вместо этого напрямую помещать $(builddir)/extralib/libmy-secret-lib.a в переменную LDFLAGS/LIBADD для окончательной общей библиотеки.

Это, к сожалению, приводит к предупреждению libtool о непереносимости и необходимости создания "самодельной удобной библиотеки" с помощью -fPIC -- даже если она была построена таким образом и полностью переносима. ...LIBTOOLFLAGS = --silent недостаточно, чтобы скрыть это кричащее предупреждение, к сожалению, но результат хороший: требуемые символы скопированы в окончательную библиотеку, dependency_libs незапятнанные, и никаких хаков (таких как: https://gitorious.org/libguestfs/libguestfs/source/c46bedf925cd9c6c9a9cbaeelibffdency.sh >) обязательно.

person andybuckley    schedule 31.01.2014
comment
И еще одно дополнение: этот способ также оказался неудобным, и, в конце концов, было проще всего преобразовать систему сборки внешней библиотеки в libtool и рассматривать ее как неотъемлемую часть моей библиотеки (с некоторым искажением пространства имен, чтобы избежать конфликтов символов, если мой lib когда-либо будет связана пользователем с одной и той же внешней библиотекой). Жаль, что libtool не может хорошо работать со статическими библиотеками, созданными в другом месте. - person andybuckley; 30.12.2014