Libtool удаляет все параметры с -M?

Question

Libtool удаляет все параметры с -M?

Я пытаюсь отследить сбой связи с файлом-файлом в Solaris. Отсутствующий файл карты вызывает следующую ошибку, когда я пытаюсь запустить наши собственные тесты:

$ ./cryptestcwd v
ld.so.1: cryptestcwd: fatal:
/export/home/cryptopp/.libs/libcryptopp.so.6: hardware capability
(CA_SUNW_HW_1) unsupported: 0x4800000  [ AES SSE4.1 ]
Killed

Я дошел до этого правила Automake. libcryptopp_la_LINK, который я считаю общим объектом, отсутствует AM_LDFLAGS, AM_LDFLAGS держит -M cryptopp.mapfile вариант.

libcryptopp_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \
$(CXXFLAGS) $(libcryptopp_la_LDFLAGS) $(LDFLAGS) -o $@

Я пытался исправить это с sed после configure работает:

libcryptopp_la_LINK = $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) \
$(LIBTOOLFLAGS) --mode=link $(CXXLD) $(AM_CXXFLAGS) \
$(CXXFLAGS) $(libcryptopp_la_LDFLAGS) -M cryptopp.mapfile $(LDFLAGS) -o $@

Я подтвердил sed успешно, но тот же тест снова не проходит. Когда команды вызываются -M <mapfile> пропал, отсутствует.

руководство по libtool Переговоры о -M Аргументы в пользу Cygwin, но не в Solaris (и обсуждение относится только к GCC, а не к другим компиляторам, таким как IBM XL C / C ++, Sun C / C ++ и LLVM Clang):

Обратите внимание, что вам также необходимо убедиться, что стандартные каталоги Unix (например, / bin, / lib, / usr, / etc) находятся в корне диска. Это означает, что вы должны установить сам Cygwin в корневой каталог C: / (или D: /, или E: / и т. Д.) — вместо рекомендуемой установки в C: / cygwin /. Кроме того, все имена файлов, используемые в системе сборки, должны быть относительными, символические ссылки не должны использоваться в деревьях каталогов источника или сборки, и следует избегать всех опций -M * для gcc, кроме -MMD.

Там нет другого упоминания о -M,

И нет диагностики, как «Удаление -M <mapfile> варианты Sun linker « или же «Предупреждение: libtool не понимает вариант -M <mapfile>«.

Мой вопрос, делает ли libtool отбрасывать -M а его аргументы почему то?

0

autotools c++libtool map-files solaris

Решение

Другие решения

Других решений пока нет …

Источник

Accepted Answer

Libtool пропускает некоторые параметры ссылок при создании библиотеки. Руководство объясняет:

При создании общей библиотеки, но не при компиляции или создании
Программа libtool удаляет некоторые флаги из командной строки, предоставленной
Пользователь. Это сделано потому, что флаги, неизвестные libtool, могут мешать
с созданием библиотеки или требует дополнительной поддержки от libtool, и
потому что пропуск флагов обычно является консервативным выбором для
успешная сборка

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

Эксперименты показывают, что -M действительно среди вариантов, которые libtool полосы. В частности, если я укажу LDFLAGS содержащий -M вариант на make командная строка, то я могу наблюдать это эхом в make вывод, когда он запускает libtool ссылка, но не в libtool«s своя echo команды link, которая фактически выполняется:

$ make LDFLAGS = «- M mapfile»

/ bin / sh ./libtool —tag = CC —mode = link gcc -g -O2 -M mapfile -o libmylib.la -rpath / usr / local / lib x.lo y.lo

libtool: ссылка: gcc -shared -fPIC -DPIC .libs / x.o .libs / y.o -O2 -Wl, -soname -Wl, libmylib.so.0 -o .libs / libmylib.so.0.0.0

libtool Документы предлагают два обходных пути для передачи параметров ссылки, которые в противном случае были бы удалены:

За добросовестный Параметры компоновщика, вы можете использовать один или несколько -Wl, или же -Xlinker варианты для передачи ваших вариантов через libtool и драйвер компоновщика для самого компоновщика. Например,
```
LDFLAGS=-Wl,-M,cryptopp.mapfile
```
Для опций, направленных конкретно на компоновщик Водитель, в документах предлагается добавить флаги в команду драйвера компилятора (CC = «gcc -M mapfile»), но это неэффективно поскольку $(CC) переменная расширяется make сформировать libtool командной строки, оставляя любые опции, выраженные в ней, открытыми для libtool для зачистки.

Кроме того, однако, есть

-XCClinker опция, с помощью которой опции могут быть переданы драйверу компоновщика (в отличие от самого компоновщика), но его поведение кажется немного странным: кажется, что игнорируются опции, которые не начинаются с дефиса (например, имя вашей карты файл).

1