On Tue, 2 Feb 2010, Hans Aberg wrote:
On 2 Feb 2010, at 15:20, Ken Raeburn wrote:
On Mac OS X (trying it on 10.5.8 PPC G4), guile-1.8.7 cannot open
dynamic library files with name extensions .dylib, but only if they
are renamed using .so instead. On the Bug-Guile list they say it
just calls libltdl, in the libtool package. I have installed latest
of both, but the problem persists:
libtool should produce modules named *.so on Darwin if you pass the
-module flag at link time. Typically, -avoid-version is used for
modules as well.
But dlopen() on Mac OS X can only open files in the native format, which
isn't ELF, and they are typically named with the .dylib file name
extension. If it finds a .so file on ELF format, all it does is reporting
it cannot be opened.
".so" doesn't mean ELF format, and on some systems including Mac OS X,
"dynamically linked shared library" (e.g., a ".dylib" file) is not the same
as "dynamically loadable object". Did you not see my earlier email to you
and the bug-guile list?
The fact is that currently Guile, which relies on libtool, cannot open .dylib
files, though it works perfectly if they are renamed .so. As for what
filenames to use, dlopen() does not care - it is something imposed by
libtool. Also, all new native DLLs (see below) on Mac OS X are named .dylib.
Unless I am missing something, the question to be answered is if Guile
requests opening modules using a name like "module.so" (assuming a
particular naming scheme), "module.la" (using libltdl as originally
intended), or bare "module" (using libltdl heuristics, which tries
several incantations, such as looking for .la, and .so).
OS-X's module loading does not care about the file extension.
Under OS-X (Leopard and later), the 'dtruss' program can be used to
see what is really going on.
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/