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
> libsodll dylib
> module sodll 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
