bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mac OS X .dylib


From: Ken Raeburn
Subject: Re: Mac OS X .dylib
Date: Sat, 30 Jan 2010 13:39:39 -0500

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]