Re: Mac OS X .dylib not working
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/
Re: slib with guile 1.9.7
Hello,
[Adding Cc: bug-guile since it’s relevant.]
Aubrey Jaffer writes:
> | Date: Mon, 1 Feb 2010 17:37:50 +0100
> | From: Petr Gajdos
> |
> | On Thu, Jan 28, 2010 at 08:59:33PM -0500, Aubrey Jaffer wrote:
> | > [...]
> | >
> | > Okay. I conditionalized the 3 forms on guile-2. I also repaired
> | > "guile.init" for Guile-1.8.6, the version my Fedora-11 system runs.
> | >
> | > The development version is updated:
> | > http://groups.csail.mit.edu/mac/ftpdir/users/jaffer/slib.zip
> | > Also, the CVS repository is updated:
> | > https://savannah.gnu.org/cvs/?group=slib
> | >
> | > Please try it out and see if it works for Guile-1.9.
> |
> | Strictly following guile manual [1] I get with guile-1.9.7
> |
> | laura:/usr/share/guile/1.9 # guile --no-autocompile -c "(use-modules
> (ice-9 slib))"
> | ERROR: In procedure sc-expand:
> | ERROR: definition in expression context in subform `browse-url' of
> | `(lambda (url)
> | (define (try cmd end)
> | (zero? (system (string-append cmd url end
> | (or (try "netscape-remote -remote 'openURL(" ")'")
> | (try "netscape -remote 'openURL(" ")'")
> | (try "netscape '" "'&")
> | (try "netscape '" "'")))
> | '
>
> Does Guile's syncase not support internal function definitions?
>
> Does either of these definitions work?
>
> (if (not (defined? 'browse-url))
> (define (browse-url url)
> (define try
> (lambda (cmd end) (zero? (system (string-append cmd url end)
> (or (try "netscape-remote -remote 'openURL(" ")'")
> (try "netscape -remote 'openURL(" ")'")
> (try "netscape '" "'&")
> (try "netscape '" "'"
>
> (if (not (defined? 'browse-url))
> (define (browse-url url)
> (letrec ((try
> (lambda (cmd end)
> (zero? (system (string-append cmd url end))
> (or (try "netscape-remote -remote 'openURL(" ")'")
> (try "netscape -remote 'openURL(" ")'")
> (try "netscape '" "'&")
> (try "netscape '" "'")
No:
scheme@(guile-user)> (if (not (defined? 'foo))(define foo 2))
Throw to key `syntax-error':
ERROR: In procedure sc-expand:
ERROR: definition in expression context in subform `foo' of `2'
I wonder whether we should hack ‘if’ to support this idiom, for backward
compatibility, since it used to be relatively common.
At any rate, the following should work both with 1.8 and 2.0 (and
probably older versions):
(if (not (defined? 'foo))
(module-define! (current-module) 'foo 2))
Thanks,
Ludo’.
Re: Mac OS X .dylib not working
Hi, Hans Aberg writes: > On 2 Feb 2010, at 17:52, Bob Friesenhahn wrote: > >> 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). [...] > handle = lt_dlopenext (fname); The Guile manually specifically tells that FNAME should not contain an extension. Hans: in [0], you said you compiled the module with “gcc -dynamiclib -lguile -o libguile-bessel.so bessel.c”. Is it the right incantation for loadable modules (not shared libraries) on Darwin? 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’. (Either way, you’d probably be better off using Libtool to create the module.) Thanks, Ludo’. [0] http://thread.gmane.org/gmane.lisp.guile.bugs/4476 [1] http://hydra.nixos.org/build/275625/log/raw
Re: Mac OS X .dylib not working
On 2 Feb 2010, at 17:52, Bob Friesenhahn wrote:
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).
On the Bug-Guile list, Ludovic Courtès said it was the last one ,
specifically the code in 'ibguile/dynl.c', which looks like:
static void *
sysdep_dynl_link (const char *fname, const char *subr)
{
lt_dlhandle handle;
handle = lt_dlopenext (fname);
if (NULL == handle)
{
SCM fn;
SCM msg;
fn = scm_from_locale_string (fname);
msg = scm_from_locale_string (lt_dlerror ());
scm_misc_error (subr, "file: ~S, message: ~S", scm_list_2 (fn,
msg));
}
return (void *) handle;
}
OS-X's module loading does not care about the file extension.
So from what you say, the problem may simply be that .dylib isn't in
the list.
Hans
Re: Mac OS X .dylib not working
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. I have only seen .bundle that are directories, also are called "plugins". 'man dlopen' says: dlopen -- load and link a dynamic library or bundle but does not specify what happens if one tries to open a bundle directory. Looking at an Internet Plug-In, I can do: file '/Library/Internet Plug-Ins/DRM Plugin.bundle/Contents/MacOS/ DRM Plugin' /Library/Internet Plug-Ins/DRM Plugin.bundle/Contents/MacOS/DRM Plugin: header for PowerPC PEF executable (PEF is the old format used on Mac OS 9 PPC.) So if one opens this file directly, it has no filename extension at all. So I suggested on the Bug-Guile list having an opening sequence, say trying: the full name, .dylib, and .so. If you think of .so as a general POSIX standard not tied to ELF, that is of course OK. Hans
Re: Mac OS X .dylib not working
Hello Hans, * Hans Aberg wrote on Mon, Feb 01, 2010 at 03:26:53PM CET: > 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. Hope that helps. Cheers, Ralf
Re: Mac OS X .dylib not working
On Feb 2, 2010, at 04:08, Hans Aberg wrote: On 2 Feb 2010, at 07:42, Ralf Wildenhues 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? Ken
Re: Mac OS X .dylib not working
On 2 Feb 2010, at 07:42, Ralf Wildenhues 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. Hans
