.def file equivalent for OS X

Question

I've found an interesting for me way of exporting functions from dll (windows) using module definition (.def) file and friendly names for export, but I can't find any information on how that can be done on Mac.

I would like to know if there is any equivalent of module definition on OS X.

Answer 1

The main part of what you're looking for (if I've understood it) can be accomplished using the -alias <symbol_name> <alternate_symbol_name> and -alias_list <filename> options to the linker (ld). You can achieve additional control using -exported_symbol <symbol> and -unexported_symbol <symbol> and their file-list counterparts -exported_symbols_list <filename> and -unexported_symbols_list <file>.

Answer 2

Using a .def file to force simpler naming conventions on exported symbols is really not the way to go - generally once you have mangling problems at that level, there is a good chance that something else will go wrong. I'm basing this on the C++ tag in your question.

Generally the compiler/linker will generate the correct mangling to match the code you're exporting if you intend on connecting C++ code so that when you try to consume it then linker errors would indicate that you're straying off binary compatibility, and linkage may be the least of your problems - y'all are straying into potentially incompatible allocators, etc.

You should export a simple "C" api, which will reduce linking complications - there is a well defined C linkage, and the routines will get simple names for linking.

This is the general purpose of the guards in .h files:

#ifdef __cplusplus
extern "C" {
#endif

… library exports …

#ifdef __cplusplus
}
#endif

This will automagically get you eminently simpler names for linking against than the convolutions you would normally see when trying to link against C++ code - as long as you #include the .h file when compiling the .cpp file, as long as there are declarations for the routines you want to export in .h that have the corresponding definitions in the .cpp they will be automatically exported demangled.

You still can use the answers offered by Ken Thomases answer - they will give you symbols visibility and symbol aliasing, but TBH, it sounds like you're trying to fit a solution you've been using in windows to another platform, but to me it seems like you've been using an incorrect approach in the windows platform in the first place.

Historical/linkage commentary:

I'm also going to mention that the .def file support on windows is really caused by the different export mechanism on windows - it originally exported symbols from .dll files by ordinal - i.e. a number so you had to use the def file to remap the linkage of names back to the number in question in order to understand things like the calling conventions. Most unix/linux systems never exported only numbered indexes, which means that the names that were defined in the API could be linked directly.
The slightly manglesome @<number> items at the end of function names exported from windows .dll files nowadays indicate the number of bytes that are needed for parameters. The __stdcall calling convention adds this in order to ensure that the caller understands that the function being called will pop that number of bytes from the stack before returning, so that the caller can clean up any possible extra parameters for the function call (this is only theoretical - variadic routines are converted to the cdecl calling convention by the compiler automatically to eliminate this issue by default).
The ABIs on other platforms don't use calling convention that can split the responsibility of stack cleanup between the caller and callee like that, so as a result, don't get mangling like that by default for 'protection'.