Избегайте -blibpath при связывании проекта Autotools в AIX

Question

Мы обнаруживаем segfault в проекте, построенном с использованием Autotools в AIX. Согласно GDB он умирает в коде запуска. Тот же проект, построенный с использованием GNUmakefile, - это хорошо. Связанная проблема здесь.

Autotools добавляет несколько необычных флагов компоновщика, и мы уверены, что это является основной причиной проблемы. Созданный Autotools Makefile находится здесь.

А также:

libtool: link: g++ -pthread -fdata-sections -ffunction-sections -pipe -g -O2 -pt
hread -o .libs/cryptestcwd cryptestcwd-test.o ...
yptestcwd-dlltest.o cryptestcwd-fipsalgt.o cryptestcwd-adhoc.o  -L./.libs -lcryp
topp -L/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0 -lstdc++ -lm -pthread
-Wl,-blibpath:/usr/local/lib:/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0:
/opt/freeware/lib/gcc/powerpc-ibm-aix7.2.0.0/7.2.0:/opt/freeware/lib/gcc/powerpc
-ibm-aix7.2.0.0/7.2.0/../../..:/usr/lib:/lib

Флаги не приходят из окружающей среды или нашего configure.ac:

-bash-4.4$ echo $LDFLAGS
-bash-4.4$ echo $LDLIBS $LIBS
-bash-4.4$

И AM_CXXFLAGS а также AM_LDFLAGS мы добавляем:

AM_CXXFLAGS:  -pthread -fdata-sections -ffunction-sections
AM_LDFLAGS:  -pthread -Wl,--demangle

Я пытался make LDFLAGS="" и переопределить флаги Autotools, но добавлены те же флаги.

Мой первый вопрос: как они перекрывают нашу LDFLAGS? Make-файлы GNU не работают таким образом. GNU всегда позволяет пользователю переопределять флаги make-файла.

Мой второй вопрос: как мы можем запретить Autotools добавлять ненужные флаги во время фазы соединения?

---

Вот наш configure.ac, Вот краткое изложение опций, которые мы добавляем после запуска ванили ./configure:

Auto-configuration complete. A summary of options are below. If
something looks wrong then please modify config.h and please report
it at http://github.com/noloader/cryptopp-autotools.

   Build triplet: powerpc-ibm-aix7.2.0.0
 Compiler target: powerpc-ibm-aix7.2.0.0
Compiler version: g++ (GCC) 7.2.0

Static library: yes
Shared library: yes

CRYPTOPP_PPC_FLAG: -mcpu=power8 -maltivec
CRYPTOPP_CHAM_FLAG: -mcpu=power7 -maltivec
CRYPTOPP_CRC_FLAG: -mcpu=power8 -maltivec
CRYPTOPP_LEA_FLAG: -mcpu=power7 -maltivec
CRYPTOPP_GCM_FLAG: -mcpu=power8 -maltivec
CRYPTOPP_AES_FLAG: -mcpu=power8 -maltivec
CRYPTOPP_SHA_FLAG: -mcpu=power8 -maltivec
CRYPTOPP_SIMECK_FLAG: -mcpu=power7 -maltivec
CRYPTOPP_SIMON_FLAG: -mcpu=power7 -maltivec
CRYPTOPP_SPECK_FLAG: -mcpu=power7 -maltivec
CRYPTOPP_SM4_FLAG: -mcpu=power7 -maltivec

Automake flags (can be overridden by user flags):
AM_CXXFLAGS:  -pthread -fdata-sections -ffunction-sections
AM_LDFLAGS:  -pthread -Wl,--demangle

User flags (overrides Automake flags on conflict):
CXXFLAGS: -g -O2
LDFLAGS:

Answer 1

Мой первый вопрос: как они перекрывают наши LDFLAGS? Make-файлы GNU не работают таким образом. GNU всегда позволяет пользователю переопределять флаги make-файла.

Автоинструменты не переопределяют ваши LDFLAGS, Это не в их силах, и в Autotools четко сформулирована философия проектирования, заключающаяся в том, что они не игнорируют решения человека, создавшего проект.

Тем не мение, LDFLAGS это не единственный источник ссылок. Также добавлены флаги компилятора, и, в частности, библиотеки для ссылки не должны быть включены в LDFLAGS (или же AM_LDFLAGS или же mytarget_LDFLAGS) вообще, потому что эти переменные (первая и точно одна из последних двух) раскрываются перед списком объектов для связи.

Но помимо всего этого, libtool добавляет флаги, которые он считает целесообразными, и вот где -Wl,-blibpath исходит от в вашем случае.

Мой второй вопрос: как мы можем запретить Autotools добавлять ненужные флаги во время фазы соединения?

Боюсь, не легко. Ваш лучший вариант, вероятно, заключается в изменении внутрипроектной копии libtool сценарий оболочки, чтобы подавить его. Это аналогично указаниям Fedora по упаковке для подавления генерации rpath записи в двоичных файлах ELF.

Вы также можете подумать о том, чтобы глубже понять, почему этот вариант вызывает у вас проблемы. Он задает путь поиска разделяемой библиотеки во время выполнения (опять-таки, как rpath), и если вы получаете различное поведение с и без, это подразумевает, что разные библиотеки динамически связываются в этих двух случаях. Это выглядит как libtool выбирает путь, который он делает, основываясь на пути поиска библиотеки времени компиляции, и если это так, то вас должно беспокоить, что библиотеки, с которыми вы ссылаетесь, не поддерживают программу во время выполнения.