Closed fullincome closed 4 years ago
В своем проекте мы использовали данную библиотеку в качестве плагина. Для этого требовалось собрать ее в качестве разделяемой библиотеки. Возможно, помимо удаления ключа "-c", стоит этот вид сборки убрать из all, чтобы не ломать сборку зависимых проектов?
У меня libmsspi.so c -c
:
> ldd libmsspi.so
not a dynamic executable
Без -c
получше:
> ldd libmsspi.so
linux-vdso.so.1 (0x00007ffc6d5d2000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f7081dc4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7081a26000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f708180e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f708141d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f7082358000)
Так что -c
уберём точно.
@fullincome можно ссылку, почему по умолчанию с динамикой будет?
Потому что так работает линковщик, указывая -lmsspi в приоритете будет динамическая библиотека: https://stackoverflow.com/questions/4422493/how-to-force-linker-to-use-shared-library-instead-of-static-library
Приоритет решений от хорошего до плохого вижу так: 1) убираем shared сборку 2) или создаем отдельную цель shared и пользуемся когда нужно: make shared 3) или в зависимых приложениях явно линкуем static: -l:libmsspi.a (совсем не хороший вариант)
Давайте так?
all: static
static: libmsspi.a
shared: libmsspi.so
msspi.o:
g++ -Wall -Wl,--no-as-needed -std=c++11 -g -O2 -fPIC -Werror -Wno-unused-function -I../third_party/cprocsp/include ../src/msspi.cpp -c -o msspi.o
libmsspi.a: msspi.o
ar cr libmsspi.a msspi.o
libmsspi.so:
g++ -Wall -Wl,--no-as-needed -std=c++11 -g -O2 -fPIC -Werror -Wno-unused-function -I../third_party/cprocsp/include -shared ../src/msspi.cpp -o libmsspi.so
clean:
rm libmsspi.so libmsspi.a msspi.o
Выглядит ок, только вот здесь подправить:
libmsspi.so:
g++ -shared -o libmsspi.so msspi.o
clean:
rm -f libmsspi.so libmsspi.a msspi.o
Коммит: d810c9a8e03f04119cf70ee9407be280a008d8c6
Shared library будет только мешать: по умолчанию линковка не будет трогать статическую библиотеку. Приложения, которые линковались с msspi будут иметь ненужную динамическую зависимость и узнают о ней не сразу. Использовать msspi динамически - не кажется правильным решением.
При обновлении версии msspi в stunnel - он не соберется: в коде ошибка, генерируется объектный файл, вместо библиотеки (не нужен ключ "-c").