On 04/22/2010 12:01 AM, Vincent Torri wrote: > > > On Wed, 21 Apr 2010, Peter O'Gorman wrote: > >> On 04/21/2010 04:00 PM, Vincent Torri wrote: >>> >>> Hey, >>> >>> A guy mentioned that problem: on mac os x, a "standard" shared lib has >>> suffix name .dylib: >>> >>> lib_LTLIBRARIES = libfoo.la --> libfoo.dylib >>> >>> but with a "module": >>> >>> pkg_LTLIBRARIES = bar.la >>> bar_la_LDFLAGS = -module -avoid-version >>> >>> then the name is bar.so and not bar.dylib >>> >>> Is it a known behavior ? If so, is it a bug ? >> >> Yes, it is known, no, it is not a bug. > > linux windows mac > lib so dll dylib > module so dll so > > mac is the only system where the module has a different name than a lib. > Why ? That complicates things for nothing (we use shrext_cmds variable > in autoconf as suffix of files that are dlopened).
Mostly for historical reasons, when Apple first introduced Mac OS X, it did not have dlopen() and could not open shared libraries at runtime, only modules. Since most modules had the .so extension, it was decided that runtime loadable modules should have the extension .so, but shared libraries, in order to be found by the static linker, have the extension .dylib. Now, the static linker will look for libfoo.dylib, libfoo.so (though this is not documented) and libfoo.a when it sees -lfoo, that was not always the case. Now the dynamic linker can load both MH_DYLIB and MH_BUNDLE file types, that was not always the case either. You can tell at configure time which extension will be used by: module=yes eval loadable_shrext=$shrext_cmds module=no eval linkable_shrext=$shrext_cmds or so. Peter _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool