#autotools #libtool
Вопрос:
В проекте, построенном и протестированном с помощью autotools, я сталкиваюсь со следующим поведением:
Тестовые двоичные файлы, расположенные в .libs папке, создаются как временные сценарии-оболочки. Их заголовок содержит некоторую информацию
# cregions1 - temporary wrapper script for .libs/cregions1
# Generated by libtool (GNU libtool) 2.4.2
#
# The cregions1 program cannot be directly executed until all the libtool
# libraries that it depends on are installed.
Некоторые, но не все, получают префикс lt- перед своим именем. Таким образом, эти тесты завершаются неудачей, так как не найдено подходящего эталонного вывода.
Приведенное выше сообщение об ошибке предполагает, что при построении тестов могут отсутствовать динамические библиотеки. Однако я еще не мог понять, что именно это такое и как я мог бы легко их включить. У кого-нибудь есть идеи, как это можно решить?
Комментарии:
1. То, что вы, кажется, описываете, не согласуется с тем, что я наблюдаю в своих проектах. Я вижу, что в проекте Automake с Libtool сами программные цели создаются в виде сценариев-оболочек, подобных тем, которые вы описываете. Затем для каждой из целей программы в ./libs есть два реальных двоичных файла, один с
lt-префиксом, а другой без. Вы действительно наблюдаете что-то еще?
Ответ №1:
В проекте, построенном и протестированном с помощью autotools, я сталкиваюсь со следующим поведением:
Тестовые двоичные файлы, расположенные в .папки libs создаются как временные сценарии-оболочки. Их заголовок содержит некоторую информацию
# cregions1 - temporary wrapper script for .libs/cregions1 # Generated by libtool (GNU libtool) 2.4.2 # # The cregions1 program cannot be directly executed until all the libtool # libraries that it depends on are installed.Некоторые, но не все, получают префикс lt — перед своим именем.
Если это действительно то, что вы видите, значит, что-то сильно нарушено в вашем проекте или в ваших автоинструментах. Но, как я подразумевал в комментариях, я подозреваю, что то, что вы видите, на самом деле несколько отличается от вашего описания.
В частности, в проекте Automake, использующем Libtool, вы должны видеть, что каждая скомпилированная целевая программа (обозначенная через foo_PROGRAMS переменную) создается в виде сценария-оболочки, такого как вы описываете. То есть сама цель строится как сценарий. Кроме того, в соответствующую папку встроены два двоичных .libs файла, один с lt- префиксом, а другой без. Опять же, .libs содержит добросовестные двоичные файлы, а не сценарии, по два для каждой целевой программы.*
Таким образом, эти тесты завершаются неудачей, так как не найдено подходящего эталонного вывода.
Вы не должны пытаться запускать двоичные файлы в .libs напрямую. Вместо этого вы должны запускать соответствующие обертки. В конце концов, это то, что вы указали, должно быть построено.** Они служат для запуска реального двоичного файла таким образом, чтобы удовлетворялись зависимости библиотек, особенно зависимости от удаленных общих библиотек, включенных в один и тот же проект.
Вы можете понять, что это примерно аналогично тому, как Automake Libtool создает общие библиотеки: артефакт, указанный в файле Makefile.am-это «архив libtool» с расширением .la . Это файл метаданных, который ссылается на другие встроенные артефакты .libs/ .
Приведенное выше сообщение об ошибке предполагает, что при построении тестов могут отсутствовать динамические библиотеки.
Это не сообщение об ошибке. Это комментарий, объясняющий (часть) причину сценария-оболочки.
Однако я еще не мог понять, что именно это такое и как я мог бы легко их включить. У кого-нибудь есть идеи, как это можно решить?
Если на самом деле ваша сборка создает ожидаемые артефакты в соответствии с описанным мной шаблоном, то вы, похоже, изо всех сил стараетесь усложнить себе жизнь. Вы должны иметь возможность запускать встроенные двоичные файлы с помощью сценариев-оболочек. Это как раз и есть их цель. Идея заключается в том, что они прозрачно скрывают сложность запуска удаленных двоичных файлов (которые могут включать RPATH и другие интересные вещи), в том числе те, которые полагаются на удаленные общие библиотеки, принадлежащие одному и тому же проекту (которые во многих случаях по умолчанию не будут обнаружены динамическим компоновщиком).
Если ваша сборка не создает ожидаемых артефактов и шаблонов, то вы, вероятно, делаете что-то, что мешает, например, играете в игры с символическими ссылками или предоставляете пользовательские правила, которые искажают содержимое .libs/ (возможно, непреднамеренно).
*Возможно, при некоторых обстоятельствах для каждой цели будет создано меньше двоичных файлов, но при любых обстоятельствах вы должны видеть, что .libs/ они содержат только реальные двоичные файлы, а не сценарии-оболочки.
**Под этим я подразумеваю, что сценарии-оболочки создаются с именами и местоположениями, которые вы указали для разыскиваемых целей. Предположительно , вы не имеете в виду, что подобные сценарии будут установлены в системе, когда вы make install , и действительно, вы этого не понимаете. make install установим реальные двоичные файлы.