Re: Mac OS X .dylib not working

[Ludovic Courtès]

Hi,

Ken Raeburn <address@hidden> writes:

> [Is Hans on one of these lists now?  His original message to bug-guile
> said not and asked to be cc'ed.]

We might have lost him then.  ;-)

> On Feb 2, 2010, at 13:01, Ludovic Courtès wrote:
>> The Guile manually specifically tells that FNAME should not contain
>> an extension.
>
> That could be unfortunate, since it means that unlike other Mac
> applications, a Guile application would not be able to customize its
> plugin names to use Foo.quuxplugin type names.  Guile apps would be
> limited to a hardcoded set of suffixes then, right?

Guile doesn’t modify FNAME, it just passes it on to ‘lt_dlopenext ()’.

>> Surprisingly, I just noticed that Guile itself doesn’t use the
>> ‘-module’ option of Libtool when creating its ‘libguile-srfi-srfi-1’
>> module (which is meant to be dlopened *or* directly linked against),
>> although this has never caused any problems on OS X.  If you search
>> for that in [1], ‘libguile-srfi-srfi-1’ is actually created with
>> ‘-dynamiclib’.
>
> Current versions of Mac OS X can load shared libraries (.dylib) as
> well as the bundle format that seems to have been the original plugin
> form (.so, .bundle, ...).  So in practice, assuming you can dlopen and
> dlclose a shared library works pretty well, though I gather it might
> not have worked as well in earlier releases.

OK.

> But we should also support the format(s) intended for plugin modules
> as well, and the naming conventions (which appear to be somewhat
> varied, and less consistent than on other OSes).

Since libguile-srfi-srfi-1 is intended both to be dlopened and linked
directly against, we’d need to link it twice, once with ‘-module’ and
another one to create the shared library.

I can’t imagine myself tweaking the build system in non-trivial ways to
accommodate old versions of OS X, though...

Thanks,
Ludo’.