.def эквивалент файла для OS X

Question

Я нашел интересный для меня способ экспорта функций из dll (windows) с использованием файла определения модуля (.def) и дружественных имен для экспорта, но я не могу найти никакой информации о как это можно сделать на Mac.

Я хотел бы знать, если есть какие-либо эквивалент определения модуля на OS X.

Answer 1

Основная часть того, что вы ищете (если я понял это) может быть достигнуто с помощью -alias <symbol_name> <alternate_symbol_name> и -alias_list <filename> варианты компоновщика (ld). Вы можете достичь дополнительного контроля с помощью -exported_symbol <symbol> и -unexported_symbol <symbol> и их сопоставителей по файлам -exported_symbols_list <filename> и -unexported_symbols_list <file>.

Answer 2

Использование DEF-файл, чтобы заставить простые соглашения об именах на экспортируемых символах действительно не путь - как правило, после того как вы коверкая проблемы на этом уровне, есть хороший шанс, что что-то еще пойдет не так. Я основываю это на теге C++ в вашем вопросе.

Как правило, компилятор/компоновщик генерирует правильное манипулирование в соответствии с кодом, который вы экспортируете, если вы собираетесь подключить код C++, чтобы при попытке его использовать ошибки компоновщика указывали бы, что вы отклоняетесь от бинарной совместимости , и связь может быть наименее из ваших проблем - вы отклоняетесь от потенциально несовместимых распределителей и т. д.

Вы должны экспортировать простой «C» api, что уменьшит сложности связывания - существует четко определенная C-связь , и подпрограммы получат простые имена для связывания.

Это общая цель охранников в .h файлов:

#ifdef __cplusplus 
extern "C" { 
#endif 

… library exports … 

#ifdef __cplusplus 
} 
#endif 

Это автомагический получить вам чрезвычайно простые имена для связи с чем извилинами вы обычно видите при попытке связать с кодом C++ - до тех пор, пока вы #include файл .h при компиляции файла .cpp, если существуют объявления для подпрограмм, которые вы хотите экспортировать, в .h, которые имеют соответствующие определения в .cpp, они будут автоматически экспортированы в порядке.

Вы по-прежнему можете использовать ответы, предлагаемые Ken Thomases, - они дадут вам видимость символов и наложение символов, но TBH, похоже, вы пытаетесь подобрать решение, которое вы использовали в Windows, на другой платформе , но для меня кажется, что вы использовали неправильный подход на платформе Windows в первую очередь.

Исторических/связь Комментарий:

Я также хочу упомянуть о том, что поддержка .def файла на окнах действительно вызвана различным механизмом экспорта на окнах - он изначально экспортируемые символы из .dll файлов по порядковому номеру - т.е. число, поэтому вам пришлось использовать файл def, чтобы переназначить привязку имен обратно к указанному числу, чтобы понимать такие вещи, как соглашения о вызовах. Большинство систем unix/linux никогда не экспортировали только нумерованные индексы, а это означает, что имена, которые были определены в API, могут быть связаны напрямую.
Немного искусственные @<number> элементов в конце имен функций, экспортированных из окон. .dll файлы в настоящее время указывают количество байтов, необходимых для параметров.Вызывающее соглашение __stdcall добавляет это, чтобы убедиться, что вызывающий абонент понимает, что вызываемая функция выталкивает это количество байт из стека перед возвратом, так что вызывающий может очистить любые возможные дополнительные параметры для вызова функции (это только теоретические - вариационные процедуры автоматически преобразуются в соглашение о вызове cdecl компилятором, чтобы устранить эту проблему по умолчанию).
ABI на других платформах не используют соглашение о вызовах, которое может разделить ответственность за очистку стека между вызывающим и вызываемым подобным образом, поэтому в результате не создавайте так, как это делается для защиты.