On Jan 30, 2010, at 09:41, Hans Aberg wrote:
[I'm not on this list, so please cc me.]
It seems guile-1.8.7 does not admit dynamic library file name
extensions .dylib, but only .so, on Mac OS X (tried 10.5.8. PPC G4),
despite the manual saying guile should adapt to local standards. The
example in the manual sec. 4.2.1 works fine with
gcc -dynamiclib -lguile -o libguile-bessel.so bessel.c
but not if changed to libguile-bessel.dylib, giving the error within
guile:
standard input:2:1: file: "libguile-bessel", message: "file not
found"
The Mac OS X situation is a bit more complicated than on "normal" ELF-
based UNIX systems; shared libraries and dynamically loadable objects
are not the same thing. It's easy to assume they're equivalent when
working mostly on ELF or Windows systems where .so or .dll files work
for both, but it's not always true. GNU libtool even has options for
creating loadable modules as distinct from regular shared libraries.
See for example http://www.finkproject.org/doc/porting/porting.en.html#shared.lib-and-mod
for one brief discussion of shared libraries versus "bundles" on the
Mac, and how the ".so" suffix is often used for loadable objects by
convention in ported UNIX software (not just in fink, but in the OS: /
usr/lib/pam/*.so, /usr/lib/sasl2/*.so), though I see a lot of
".bundle" names on my system too. Further confusing the matter:
* The term "bundle" seems to be used in Apple documentation both for
a particular type of file generated by the linker for loadable objects
-- the linker has different flags for them vs shared libraries -- and
a directory structure used for distributing a collection of files as
an application, framework, or plugin.
* The modern dlopen implementation on the Mac (it wasn't there at
all in 10.0) seems capable of loading both "bundles" (the file version
I think) and regular Mac shared libraries. In 10.4, dlclose()
couldn't unload a dynamic library but could unload a bundle; in 10.5,
it can unload both. So it's unclear how relevant the distinction
between "loadable objects" and "shared libraries" is any more, at
least if you're targeting 10.5 or 10.6 as your minimum required OS
version. One distinction I haven't (yet) seen mentioned as having
gone away is that bundles can reference symbols from the main
application, but dynamic libraries cannot.
See also http://lists.apple.com/archives/darwin-dev/2008/Dec/msg00045.html
...
http://developer.apple.com/Mac/library/documentation/DeveloperTools/Conceptual/MachORuntime/Reference/reference.html
describes the Mach-O file types, and says ".bundle" is the
conventional suffix for plugins.
So, in short, one could argue that looking only for ".so" for
dynamically loadable objects *is* conforming to (one set of) standards
for the Mac, annoying though it may be.
On Mac OS X, it should probably look for .dylib first, and
perhaps .so for backwards compatibility.
I think perhaps it should try without a suffix (in case the
application code specifies it), then both of these and maybe also
".bundle", though I don't have a strong sense which order they should
be tried in.
Ken
