Mac OS X .dylib

Mac OS X .dylib

[Hans Aberg]

[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"

On Mac OS X, it should probably look for .dylib first, and perhaps .so  
for backwards compatibility.

   Hans

Re: Mac OS X .dylib

[Ludovic Courtès]

Hello,

Hans Aberg <haberg@math.su.se> writes:

> 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 abstraction over file name extensions is handled by Libtool’s
libltdl, used in ‘libguile/dynl.c’.  Which version of Libtool/ltdl are
you using?  Did you try adding the directory where the ‘.dylib’ is to
$DYLD_LIBRARY_PATH?

Thanks,
Ludo.

Re: Mac OS X .dylib

[Ken Raeburn]

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

Re: Mac OS X .dylib

[Andy Wingo]

Hello Hans,

On Sat 30 Jan 2010 15:41, Hans Aberg <haberg@math.su.se> writes:

> 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)

I think your example shold work, but it's something that's totally
handled by libltdl. Are you using the latest libltdl?

Note also that libltdl's error messages often aren't the most
appropriate, due to another bug:

  http://thread.gmane.org/gmane.comp.gnu.libtool.general/10621

This (often) makes all failures come out as "file not found".

So try using a newer libltdl, and if that fails, bug-libtool@gnu.org is
probably the place to go.

A
-- 
http://wingolog.org/

Re: Mac OS X .dylib

[Hans Aberg]

On 30 Jan 2010, at 19:37, Ludovic Courtès wrote:

> The abstraction over file name extensions is handled by Libtool’s
> libltdl, used in ‘libguile/dynl.c’.  Which version of Libtool/ltdl are
> you using?

I took down the latest stable before trying to compile guile:
   libtool --version
   ltmain.sh (GNU libtool) 2.2

> Did you try adding the directory where the ‘.dylib’ is to
> $DYLD_LIBRARY_PATH?

No, all was installed with standard './configure && make && make  
install', without tweaks.

If you want me try something, please let me know.

   Hans

Re: Mac OS X .dylib

[Hans Aberg]

On 30 Jan 2010, at 19:39, Ken Raeburn wrote:

> 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.

Sure, it would be best to only load .dylib, but I suspect that there  
might be .dylib libraries with the .so extension on Mac OS X, due to  
past practice. Then such programs will suddenly break. One program  
using Guile is LilyPond, and I have a vague memory of they mentioning  
the .so problem on Mac OS X, but I do not recall details.

If .dylib fails and it tries .so which isn't on the .dylib format,  
then the function should give an error. So it is harmless.

   Hans

Re: Mac OS X .dylib

[Hans Aberg]

On 30 Jan 2010, at 20:30, Andy Wingo wrote:

>> 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)
>
> I think your example shold work, but it's something that's totally
> handled by libltdl. Are you using the latest libltdl?

I have now update to latest
   libtool --version
   ltmain.sh (GNU libtool) 2.2.6b
and the README says that libltdl should be a part of it; however, I  
just made an install of the libtools package. I also re-unpacked  
guile-1.8.7, and './configure && make && make install'.

There is no change: .dylib fails; .so works.

> Note also that libltdl's error messages often aren't the most
> appropriate, due to another bug:
>
>  http://thread.gmane.org/gmane.comp.gnu.libtool.general/10621
>
> This (often) makes all failures come out as "file not found".

Since it works if I change to .so, it seems to only be that file name  
problem.

> So try using a newer libltdl, and if that fails, bug-libtool@gnu.org  
> is
> probably the place to go.

Ah - list chasing. :-)

   Hans