Maurice Lombardi wrote:
Is there something esoteric in Mac OS X, like /sbin/ldconfig to register .so dynamic libraries in linux ?
No, but one issue is install names
(from the OS X ld man page http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/ld.1.html, man pages for OS X tools are here https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/manpages-mpindex.html
-install_name name
Sets an internal "install path" (LC_ID_DYLIB) in a dynamic library. Any clients linked against the library will record that path as the way dyld should locate this library. If this option is not specified, then the -o path will be used. This option is also called -dylib_install_name for compatibility.
In other words, when creating the library, you must know (and record in the lib itself) where it will be installed (e.g. in /usr/local/lib). otool -D displays the install name https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/otool.1.html. install_name_tool http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/install_name_tool.1.html
can change the install name of an existing dylib. The new name can not be longer than the old name, unless -headerpad_max_install_names was passed to ld when the dylib was built.
Note that an install name can be relative to an executable, e.g. "@executable_path/../lib/libXXX.dylib" when the executable is an application package.
You can find our full discussion in the GRX list archive at http://www.g-n-u.de/pipermail/grx/
./configure --target=osx
Is there a reason using --target=osx, rather than e.g. --target=i686-apple-darwin ? I assume the --target line is needed for a cross build only, because config can "guess" it ?
There is a tool named lipo https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/lipo.1.html that combines multiple architectures into one binary. Apple gcc https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/gcc.1.html has this ability built-in
-arch arch Compile for the specified target architecture arch. The allowable values are i386, x86_64, ppc and ppc64. Multiple options work, and direct the compiler to produce "universal" binaries including object code for each architecture specified with -arch. This option only works if assembler and libraries are available for each architecture specified. (APPLE ONLY)
+# the apple linker ld has no option -s
The option was removed, but there are other options, see http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/ld.1.html and there is a separate strip tool https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/strip.1.html. However, one wouldn't want to remove all symbol info from a dynamic library, as at least the entry points must have their name saved. For a dynamic lib e.g. strip -x - r -u could be used.
Also, Apple ld can do smart linking, which dramatically reduces the size of binaries
-dead_strip Remove functions and data that are unreachable by the entry point or exported symbols.
The contents of a dynamic lib can be viewed with otool https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/otool.1.html or nm https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/nm.1.html
There is a separate tool dsymutil https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man1/dsymutil.1.html
to produce archived DWARF debug symbol files, separate from the .dylib.
These are a few points that came to my mind for Mac OS X.
Regards,
Adriaan van Os www.microbizz.nl