Не выставлять символы из используемой библиотеки в собственной статической библиотеке

Я пишу многоразовую статическую библиотеку для iPhone, следуя инструкциям здесь.

Я хочу использовать minizip в своей внутренней библиотеке, но не хочу показывать ее пользователю.

Пользователь должен иметь возможность включать minizip самостоятельно, возможно, другую версию, а не создавать конфликты с моей "внутренней" версией minizip.

Возможно ли это?

Edit:

Я попробовал добавить -fvisibility=hidden к дополнительным флагам компилятора для файлов minizip и изменениям функций __private_extern__ и __attribute__((visibility("hidden"))), но он все еще, кажется, создает определенные внешние символы:

00000918 T _unzOpen
0000058e T _unzOpen2
00001d06 T _unzOpenCurrentFile
00001d6b T _unzOpenCurrentFile2
...

Изменить # 2:

По-видимому, символы, помеченные этими аннотациями, сделаны только линкером, что никогда не происходит, когда Xcode создает источники, поскольку он добавляет параметр -c ( "Скомпилируйте или создайте исходные файлы, но не связывайтесь" ).

Ответы

Ответ 1

Вы можете переименовать весь экспортированный символ из minizip с помощью objcopy.

что-то вроде

objcopy -redefine-sym=minizip.syms yourstaticlibray.a

и minizip.syms

_unzOpen     _yourownprefix_unzOpen
_unzOpen2    _yourownprefix_unzOpen2
...          ...

Нет взаимодействия, если исполняемый файл связан с другими minizip.a и yourstaticlibray.a, и поскольку вы переименовали весь символ в yourstaticlibray.a, ваш вызов внутри yourstaticlibray.a до minizip будет использовать префиксный символ, а не unzOpen.

Ответ 2

Поскольку статическая библиотека представляет собой не что иное, как набор файлов .o(которые еще не связаны, как вы уже упоминали), единственный способ полностью скрыть присутствие minizip из внешнего мира - это как-то скомпилировать minizip и вашу библиотеку вместе как единый блок компиляции и сделать minizip функции/переменные static.

Вы можете посмотреть, как SQLite выполняет процесс "амальгамации", который превращает исходный код библиотеки в один .c файл для дальнейшей компиляции: SQLite Амальгамирование.

В качестве бонуса вы получите лучшую оптимизацию (действительно недавние GCC и Binutils могут оптимизировать время соединения, но эта функциональность еще не выпущена).