Hi, Ken Raeburn <raeb...@raeburn.org> 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’.