* Mac OS X .dylib not working @ 2011-03-03 19:53 Hans Aberg 0 siblings, 0 replies; 31+ messages in thread From: Hans Aberg @ 2011-03-03 19:53 UTC (permalink / raw) To: bug-libtool; +Cc: Guile bug, Ludovic Courtès [I'm not on the bug-libtool list, so please cc me.] Despite being reported a year ago, Guile can still not open dynamic libraries ending with .dylib on Mac OS X. Looking throw the past discussion, it looks as though developers of the one package hold the opinion that those of the other package should do the fix. So I am merely reporting it, cross-linking, so that you can figure out who guys should do the fix. :-) So guile-2.0.0 using libltdl.7.dylib of libtool-2.4, can on Mac OS X 10.6.6 only open a dynamic library if the name of what it actually opens ends in .so (say by making a soft link using 'ln -s'); if it ends in .dylib, it cannot open it, even if the full name is given. See http://lists.gnu.org/archive/html/bug-guile/2011-03/msg00008.html http://lists.gnu.org/archive/html/guile-devel/2011-03/msg00021.html Mac OS X does not care about file name extensions; .dylib is just a convention for native dynamic libraries. So the wanted behavior is to first try opening a library without adding an extension, and then try out different endings. On Mac OS X, it would be best trying out .dylib first - I haven't seen any other ending in use. Hans ^ permalink raw reply [flat|nested] 31+ messages in thread
* Mac OS X .dylib not working @ 2011-03-03 19:32 Hans Åberg 2011-03-03 19:56 ` Michael Ellis 2011-03-04 3:00 ` Bob Friesenhahn 0 siblings, 2 replies; 31+ messages in thread From: Hans Åberg @ 2011-03-03 19:32 UTC (permalink / raw) To: bug-libtool; +Cc: Guile bug, Ludovic Courtès [I'm not on the bug-libtool list, so please cc me.] Despite being reported a year ago, Guile can still not open dynamic libraries ending with .dylib on Mac OS X. Looking throw the past discussion, it looks as though developers of the one package hold the opinion that those of the other package should do the fix. So I am merely reporting it, cross-linking, so that you can figure out who guys should do the fix. :-) So guile-2.0.0 using libltdl.7.dylib of libtool-2.4, can on Mac OS X 10.6.6 only open a dynamic library if the name of what it actually opens ends in .so (say by making a soft link using 'ln -s'); if it ends in .dylib, it cannot open it, even if the full name is given. See http://lists.gnu.org/archive/html/bug-guile/2011-03/msg00008.html http://lists.gnu.org/archive/html/guile-devel/2011-03/msg00021.html Mac OS X does not care about file name extensions; .dylib is just a convention for native dynamic libraries. So the wanted behavior is to first try opening a library without adding an extension, and then try out different endings. On Mac OS X, it would be best trying out .dylib first - I haven't seen any other ending in use. Hans ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2011-03-03 19:32 Hans Åberg @ 2011-03-03 19:56 ` Michael Ellis 2011-03-04 2:59 ` Peter O'Gorman 2011-03-04 3:00 ` Bob Friesenhahn 1 sibling, 1 reply; 31+ messages in thread From: Michael Ellis @ 2011-03-03 19:56 UTC (permalink / raw) To: Hans Åberg; +Cc: Guile bug, Ludovic Courtès, bug-libtool On Thu, Mar 3, 2011 at 2:32 PM, Hans Åberg <hans.aberg-1@telia.com> wrote: > [I'm not on the bug-libtool list, so please cc me.] > > Despite being reported a year ago, Guile can still not open dynamic libraries ending with .dylib on Mac OS X. Looking throw the past discussion, it looks as though developers of the one package hold the opinion that those of the other package should do the fix. So I am merely reporting it, cross-linking, so that you can figure out who guys should do the fix. :-) > > So guile-2.0.0 using libltdl.7.dylib of libtool-2.4, can on Mac OS X 10.6.6 only open a dynamic library if the name of what it actually opens ends in .so (say by making a soft link using 'ln -s'); if it ends in .dylib, it cannot open it, even if the full name is given. > > See > http://lists.gnu.org/archive/html/bug-guile/2011-03/msg00008.html > http://lists.gnu.org/archive/html/guile-devel/2011-03/msg00021.html > > Mac OS X does not care about file name extensions; .dylib is just a convention for native dynamic libraries. > > So the wanted behavior is to first try opening a library without adding an extension, and then try out different endings. On Mac OS X, it would be best trying out .dylib first - I haven't seen any other ending in use. > > Hans I completely agree. FWIW, in section quoted below, the libtool manual appears to promise that lt_dlopenext() will respect the conventions of the host platform with regard to filename extensions for dynamic libraries. ... — Function: lt_dlhandle lt_dlopenext (const char *filename) The same as lt_dlopen, except that it tries to append different file name extensions to the file name. If the file with the file name filename cannot be found libltdl tries to append the following extensions: -- the libtool archive extension .la -- the extension used for native dynamically loadable modules on the host platform, e.g., .so, .sl, etc. ... from http://www.gnu.org/software/libtool/manual/html_node/Libltdl-interface.html#Libltdl-interface Cheers, Mike ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2011-03-03 19:56 ` Michael Ellis @ 2011-03-04 2:59 ` Peter O'Gorman 2011-03-04 3:41 ` Michael Ellis ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Peter O'Gorman @ 2011-03-04 2:59 UTC (permalink / raw) To: Michael Ellis Cc: Guile bug, Ludovic Courtès, Hans Åberg, bug-libtool On 03/03/2011 01:56 PM, Michael Ellis wrote: > On Thu, Mar 3, 2011 at 2:32 PM, Hans Åberg<hans.aberg-1@telia.com> wrote: >> [I'm not on the bug-libtool list, so please cc me.] >> >> Despite being reported a year ago, Guile can still not open dynamic libraries ending with .dylib on Mac OS X. Looking throw the past discussion, it looks as though developers of the one package hold the opinion that those of the other package should do the fix. So I am merely reporting it, cross-linking, so that you can figure out who guys should do the fix. :-) >> >> So guile-2.0.0 using libltdl.7.dylib of libtool-2.4, can on Mac OS X 10.6.6 only open a dynamic library if the name of what it actually opens ends in .so (say by making a soft link using 'ln -s'); if it ends in .dylib, it cannot open it, even if the full name is given. >> >> See >> http://lists.gnu.org/archive/html/bug-guile/2011-03/msg00008.html >> http://lists.gnu.org/archive/html/guile-devel/2011-03/msg00021.html >> >> Mac OS X does not care about file name extensions; .dylib is just a convention for native dynamic libraries. The static linker when it sees a -l flag will look for files beginning with "lib" and ending in ".dylib", ".so" (though this is recent and perhaps not documented) and ".a". So, I think you could say that it cares about file name extensions. >> >> So the wanted behavior is to first try opening a library without adding an extension, and then try out different endings. On Mac OS X, it would be best trying out .dylib first - I haven't seen any other ending in use. It does seem as though guile should sometimes be trying lt_dlopen() first - then libltdl will attempt to open whatever it's given. > > -- the libtool archive extension .la > -- the extension used for native dynamically loadable modules on the > host platform, e.g., .so, .sl, etc. On Mac OS X, libtool's idea of the native dynamically loadable module extension is ".so", and it's not going to change. However, I can see the point that libltdl should try .dylib as well as .so for lt_dlopenext on Mac OS X. I will come up with a patch for that. Peter ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2011-03-04 2:59 ` Peter O'Gorman @ 2011-03-04 3:41 ` Michael Ellis 2011-03-04 8:59 ` Andy Wingo 2011-03-04 9:44 ` Hans Aberg 2 siblings, 0 replies; 31+ messages in thread From: Michael Ellis @ 2011-03-04 3:41 UTC (permalink / raw) To: Peter O'Gorman Cc: Guile bug, Ludovic Courtès, Hans Åberg, bug-libtool On Thu, Mar 3, 2011 at 9:59 PM, Peter O'Gorman <peter@pogma.com> wrote: > > However, I can see the point that libltdl should try .dylib as well as .so > for lt_dlopenext on Mac OS X. I will come up with a patch for that. > > Peter Thanks, Peter. I'll be happy to test it. Cheers, Mike ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2011-03-04 2:59 ` Peter O'Gorman 2011-03-04 3:41 ` Michael Ellis @ 2011-03-04 8:59 ` Andy Wingo 2011-03-04 9:44 ` Hans Aberg 2 siblings, 0 replies; 31+ messages in thread From: Andy Wingo @ 2011-03-04 8:59 UTC (permalink / raw) To: Peter O'Gorman Cc: Ludovic Courtès, Åberg, bug-libtool, Guile bug Hi Peter, On Fri 04 Mar 2011 03:59, Peter O'Gorman <peter@pogma.com> writes: >>> So the wanted behavior is to first try opening a library without >>> adding an extension, and then try out different endings. On Mac OS >>> X, it would be best trying out .dylib first - I haven't seen any >>> other ending in use. > > It does seem as though guile should sometimes be trying lt_dlopen() > first - then libltdl will attempt to open whatever it's given. Guile only does this, for the record; we rely entirely on ltdl to do the right thing, which it usually does. Thanks! > However, I can see the point that libltdl should try .dylib as well as > .so for lt_dlopenext on Mac OS X. I will come up with a patch for that. And thanks for this too :-) Andy -- http://wingolog.org/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2011-03-04 2:59 ` Peter O'Gorman 2011-03-04 3:41 ` Michael Ellis 2011-03-04 8:59 ` Andy Wingo @ 2011-03-04 9:44 ` Hans Aberg 2011-03-04 18:07 ` Peter O'Gorman 2 siblings, 1 reply; 31+ messages in thread From: Hans Aberg @ 2011-03-04 9:44 UTC (permalink / raw) To: Peter O'Gorman; +Cc: Guile bug, Ludovic Courtès, bug-libtool On 4 Mar 2011, at 03:59, Peter O'Gorman wrote: >>> Mac OS X does not care about file name extensions; .dylib is just a convention for native dynamic libraries. > > The static linker when it sees a -l flag will look for files beginning with "lib" and ending in ".dylib", ".so" (though this is recent and perhaps not documented) and ".a". So, I think you could say that it cares about file name extensions. One is free to implement programs that do such things. >>> So the wanted behavior is to first try opening a library without adding an extension, and then try out different endings. On Mac OS X, it would be best trying out .dylib first - I haven't seen any other ending in use. > > It does seem as though guile should sometimes be trying lt_dlopen() first - then libltdl will attempt to open whatever it's given. That might be an hack. >> -- the libtool archive extension .la >> -- the extension used for native dynamically loadable modules on the >> host platform, e.g., .so, .sl, etc. > > On Mac OS X, libtool's idea of the native dynamically loadable module extension is ".so", and it's not going to change. > > However, I can see the point that libltdl should try .dylib as well as .so for lt_dlopenext on Mac OS X. I will come up with a patch for that. The important thing is to try .dylib - all libraries I have sen use it. It can of course try .so as well. Hans ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2011-03-04 9:44 ` Hans Aberg @ 2011-03-04 18:07 ` Peter O'Gorman 2011-03-04 18:47 ` Ralf Wildenhues 0 siblings, 1 reply; 31+ messages in thread From: Peter O'Gorman @ 2011-03-04 18:07 UTC (permalink / raw) To: Hans Aberg; +Cc: Guile bug, Ludovic Courtès, bug-libtool, libtool-patches [-- Attachment #1: Type: text/plain, Size: 593 bytes --] On 03/04/2011 03:44 AM, Hans Aberg wrote: > On 4 Mar 2011, at 03:59, Peter O'Gorman wrote: > The important thing is to try .dylib - all libraries I have sen use it. It can of course try .so as well. Patch. Fails new testcase before (well, "new" testcase as in copy & pasted lt_dlopenext testcase and slightly modified it), passes after. .dylib is tried after .so so there is no potentially surprising change in behaviour for existing applications. Oh, I forgot a NEWS entry, will add: "On Mac OS X .dylib is now tried as well as .so with lt_dlopenext" there before pushing. Ok? Peter [-- Attachment #2: 0001-On-Mac-OS-X-try-.dylib-as-well-as-.so-with-lt_dlopen.patch --] [-- Type: text/x-patch, Size: 9548 bytes --] From 9321b9aa351a1532ca9511d2aa1e1e174b9ffbd6 Mon Sep 17 00:00:00 2001 From: Peter O'Gorman <peter@pogma.com> Date: Fri, 4 Mar 2011 12:00:23 -0600 Subject: [PATCH] On Mac OS X try .dylib as well as .so with lt_dlopenext * libltdl/m4/ltdl.m4: Define extra extension if module extension differs from shared lib extension. * libltdl/ltdl.c: Use it. * tests/darwin.at: Test it. Reported by Hans Aberg, Michael Ellis, and others. --- ChangeLog | 9 ++ libltdl/ltdl.c | 19 +++++ libltdl/m4/ltdl.m4 | 7 ++ tests/darwin.at | 221 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 256 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 7f74eab..d8fa215 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2011-03-04 Peter O'Gorman <peter@pogma.com> + + On Mac OS X try .dylib as well as .so with lt_dlopenext + * libltdl/m4/ltdl.m4: Define extra extension if module extension + differs from shared lib extension. + * libltdl/ltdl.c: Use it. + * tests/darwin.at: Test it. + Reported by Hans Aberg, Michael Ellis, and others. + 2011-02-12 Peter O'Gorman <peter@pogma.com> Install ltmain.sh without execute bit set. diff --git a/libltdl/ltdl.c b/libltdl/ltdl.c index be1e4c0..942ed91 100644 --- a/libltdl/ltdl.c +++ b/libltdl/ltdl.c @@ -80,6 +80,11 @@ static const char libprefix[] = LT_LIBPREFIX; #if defined(LT_MODULE_EXT) static const char shlib_ext[] = LT_MODULE_EXT; #endif +/* If the loadable module suffix is not the same as the linkable + * shared library suffix, this will be defined. */ +#if defined(LT_SHARED_EXT) +static const char shared_ext[] = LT_SHARED_EXT; +#endif #if defined(LT_DLSEARCH_PATH) static const char sys_dlsearch_path[] = LT_DLSEARCH_PATH; #endif @@ -1537,6 +1542,9 @@ has_library_ext (const char *filename) #if defined(LT_MODULE_EXT) || (streq (ext, shlib_ext)) #endif +#if defined(LT_SHARED_EXT) + || (streq (ext, shared_ext)) +#endif )) { return 1; @@ -1682,6 +1690,17 @@ lt_dlopenadvise (const char *filename, lt_dladvise advise) if (handle || ((errors > 0) && !file_not_found ())) return handle; #endif + +#if defined(LT_SHARED_EXT) + /* Try appending SHARED_EXT. */ + LT__SETERRORSTR (saved_error); + errors = try_dlopen (&handle, filename, shared_ext, advise); + + /* As before, if the file was found but loading failed, return now + with the current error message. */ + if (handle || ((errors > 0) && !file_not_found ())) + return handle; +#endif } /* Still here? Then we really did fail to locate any of the file diff --git a/libltdl/m4/ltdl.m4 b/libltdl/m4/ltdl.m4 index 42e07e9..c256e08 100644 --- a/libltdl/m4/ltdl.m4 +++ b/libltdl/m4/ltdl.m4 @@ -553,12 +553,19 @@ AC_CACHE_CHECK([which extension is used for runtime loadable modules], [ module=yes eval libltdl_cv_shlibext=$shrext_cmds +module=no +eval libltdl_cv_shrext=$shrext_cmds ]) if test -n "$libltdl_cv_shlibext"; then m4_pattern_allow([LT_MODULE_EXT])dnl AC_DEFINE_UNQUOTED([LT_MODULE_EXT], ["$libltdl_cv_shlibext"], [Define to the extension used for runtime loadable modules, say, ".so".]) fi +if test "$libltdl_cv_shrext" != "$libltdl_cv_shlibext"; then + m4_pattern_allow([LT_SHARED_EXT])dnl + AC_DEFINE_UNQUOTED([LT_SHARED_EXT], ["$libltdl_cv_shrext"], + [Define to the shared library suffix, say, ".dylib".]) +fi ])# LT_SYS_MODULE_EXT # Old name: diff --git a/tests/darwin.at b/tests/darwin.at index 4e5034e..f022f50 100644 --- a/tests/darwin.at +++ b/tests/darwin.at @@ -228,3 +228,224 @@ mv stdout expout LT_AT_CONFIGURE([LDFLAGS=-L/there/is/no/dir/here]) AT_CHECK([./libtool --config],[ignore],[expout],[ignore]) AT_CLEANUP + +AT_SETUP(darwin can lt_dlopen .dylib and .so files) + +AT_KEYWORDS([libltdl dylib]) + +# This test requires shared library support. +AT_CHECK([$LIBTOOL --features | grep 'enable shared libraries' || exit 77], + [], [ignore]) + + +eval `$LIBTOOL --config | $EGREP '^(shlibpath_var|shrext_cmds)='` + +module=no +eval shared_ext=\"$shrext_cmds\" +module=yes +eval module_ext=\"$shrext_cmds\" + +# Only bother with this test if module extension is different from +# shared extension +AT_CHECK([test "$shared_ext" != "$module_ext" || exit 77], + [], [ignore]) + +# Skip this test when called from: +# make distcheck DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install +AT_CHECK([case $LIBLTDL in #( + */_inst/lib/*) test -f $LIBLTDL || (exit 77) ;; +esac], [], [ignore]) + +prefix=`pwd`/inst +libdir=$prefix/lib +bindir=$prefix/bin +mkdir $prefix $libdir $bindir + +# This code is copied from the Autobook: +# <http://sources.redhat.com/autobook/autobook/autobook_169.html> +# so if it needs changes, be sure to notify the Autobook authors +# about them. + +AT_DATA([simple-module.c], +[[ +#include <stdio.h> + +#ifdef __cplusplus +extern "C" +#endif +int +run (const char *argument) +{ + printf ("Hello, %s!\n", argument); + return 0; +} +]]) + +AT_DATA([ltdl-loader.c], +[[ +#include <stdio.h> +#include <stdlib.h> +#ifndef EXIT_FAILURE +# define EXIT_FAILURE 1 +# define EXIT_SUCCESS 0 +#endif + +#include <limits.h> +#ifndef PATH_MAX +# define PATH_MAX 255 +#endif + +#include <string.h> +#include <ltdl.h> + +#ifndef MODULE_PATH_ENV +# define MODULE_PATH_ENV "MODULE_PATH" +#endif + +typedef int entrypoint (const char *argument); + +/* Save and return a copy of the dlerror() error message, + since the next API call may overwrite the original. */ +static char *dlerrordup (char *errormsg); + +int +main (int argc, const char *argv[]) +{ + char *errormsg = NULL; + lt_dlhandle module = NULL; + entrypoint *run = NULL; + int errors = 0; + + if (argc != 3) + { + fprintf (stderr, "USAGE: main MODULENAME ARGUMENT\n"); + exit (EXIT_FAILURE); + } + + /* Initialise libltdl. */ + errors = lt_dlinit (); + + /* Set the module search path. */ + if (!errors) + { + const char *path = getenv (MODULE_PATH_ENV); + + if (path != NULL) + errors = lt_dlsetsearchpath (path); + } + + /* Load the module. */ + if (!errors) + module = lt_dlopenext (argv[1]); + + /* Find the entry point. */ + if (module) + { + run = (entrypoint *) lt_dlsym (module, "run"); + + /* In principle, run might legitimately be NULL, so + I don't use run == NULL as an error indicator + in general. */ + errormsg = dlerrordup (errormsg); + if (errormsg != NULL) + { + errors = lt_dlclose (module); + module = NULL; + } + } + else + errors = 1; + + /* Call the entry point function. */ + if (!errors) + { + int result = (*run) (argv[2]); + if (result < 0) + errormsg = strdup ("module entry point execution failed"); + else + printf ("\t=> %d\n", result); + } + + /* Unload the module, now that we are done with it. */ + if (!errors) + errors = lt_dlclose (module); + + if (errors) + { + /* Diagnose the encountered error. */ + errormsg = dlerrordup (errormsg); + + if (!errormsg) + { + fprintf (stderr, "%s: dlerror() failed.\n", argv[0]); + return EXIT_FAILURE; + } + } + + /* Finished with ltdl now. */ + if (!errors) + if (lt_dlexit () != 0) + errormsg = dlerrordup (errormsg); + + if (errormsg) + { + fprintf (stderr, "%s: %s.\n", argv[0], errormsg); + free (errormsg); + exit (EXIT_FAILURE); + } + + return EXIT_SUCCESS; +} + +/* Be careful to save a copy of the error message, + since the next API call may overwrite the original. */ +static char * +dlerrordup (char *errormsg) +{ + char *error = (char *) lt_dlerror (); + if (error && !errormsg) + errormsg = strdup (error); + return errormsg; +} +]]) + +: ${LTDLINCL="-I$abs_top_srcdir/libltdl"} +: ${LIBLTDL="$abs_builddir/../libltdl/libltdlc.la"} + +CPPFLAGS="$LTDLINCL $CPPFLAGS" +LDFLAGS="$LDFLAGS -no-undefined" + +AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c simple-module.c], + [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o simple-module.la ]dnl + [simple-module.lo -rpath $libdir -module -avoid-version], + [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o libsimple-dylib.la ]dnl + [simple-module.lo -rpath $libdir -avoid-version], + [], [ignore], [ignore]) +AT_CHECK([$CC $CPPFLAGS $CFLAGS -c ltdl-loader.c], + [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o ltdl-loader$EXEEXT ]dnl + [ltdl-loader.$OBJEXT -dlopen self $LIBLTDL], + [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=install cp simple-module.la $libdir/simple-module.la], [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=install cp libsimple-dylib.la $libdir/libsimple-dylib.la], [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=clean rm -f simple-module.la], [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=clean rm -f libsimple-dylib.la], [], [ignore], [ignore]) + +if test "$shlibpath_var" = PATH; then + $unset shlibpath_var || shlibpath_var= +fi +rm $libdir/simple-module.la +rm $libdir/libsimple-dylib.la + +for dir in inst/lib "$libdir"; do + LT_AT_EXEC_CHECK([./ltdl-loader], [], [stdout], [ignore], + [$dir/simple-module World]) + AT_CHECK([grep "Hello, World" stdout], [], [ignore]) + LT_AT_EXEC_CHECK([./ltdl-loader], [], [stdout], [ignore], + [$dir/libsimple-dylib World]) + AT_CHECK([grep "Hello, World" stdout], [], [ignore]) +done + +AT_CLEANUP -- 1.7.3.4 ^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2011-03-04 18:07 ` Peter O'Gorman @ 2011-03-04 18:47 ` Ralf Wildenhues 2011-03-04 19:00 ` Peter O'Gorman 0 siblings, 1 reply; 31+ messages in thread From: Ralf Wildenhues @ 2011-03-04 18:47 UTC (permalink / raw) To: Peter O'Gorman; +Cc: Guile bug, Ludovic Courtès, libtool-patches [ dropping bug-libtool ] Hi Peter, * Peter O'Gorman wrote on Fri, Mar 04, 2011 at 07:07:30PM CET: > Ok? A few copyright year bumps are missing. Some minor nits inline below. Thank you, Ralf > Subject: [PATCH] On Mac OS X try .dylib as well as .so with lt_dlopenext > > * libltdl/m4/ltdl.m4: Define extra extension if module extension > differs from shared lib extension. > * libltdl/ltdl.c: Use it. > * tests/darwin.at: Test it. > Reported by Hans Aberg, Michael Ellis, and others. > --- a/tests/darwin.at > +++ b/tests/darwin.at > @@ -228,3 +228,224 @@ mv stdout expout > LT_AT_CONFIGURE([LDFLAGS=-L/there/is/no/dir/here]) > AT_CHECK([./libtool --config],[ignore],[expout],[ignore]) > AT_CLEANUP > + > +AT_SETUP(darwin can lt_dlopen .dylib and .so files) Missing m4 quotes (for style only) > +AT_KEYWORDS([libltdl dylib]) > + > +# This test requires shared library support. > +AT_CHECK([$LIBTOOL --features | grep 'enable shared libraries' || exit 77], > + [], [ignore]) > + > + > +eval `$LIBTOOL --config | $EGREP '^(shlibpath_var|shrext_cmds)='` > + > +module=no > +eval shared_ext=\"$shrext_cmds\" > +module=yes > +eval module_ext=\"$shrext_cmds\" > + > +# Only bother with this test if module extension is different from > +# shared extension > +AT_CHECK([test "$shared_ext" != "$module_ext" || exit 77], > + [], [ignore]) You can drop arguments two and three here. > +# This code is copied from the Autobook: > +# <http://sources.redhat.com/autobook/autobook/autobook_169.html> > +# so if it needs changes, be sure to notify the Autobook authors > +# about them. > +int > +main (int argc, const char *argv[]) > +{ > + char *errormsg = NULL; > + lt_dlhandle module = NULL; > + entrypoint *run = NULL; > + int errors = 0; Isn't this lacking LTDL_SET_PRELOADED_SYMBOLS(); or was that needed only for static libs (which you've excluded earlier)? > + if (argc != 3) > + { > + fprintf (stderr, "USAGE: main MODULENAME ARGUMENT\n"); > + exit (EXIT_FAILURE); > + } > + > + /* Initialise libltdl. */ > + errors = lt_dlinit (); > + > + /* Set the module search path. */ > + if (!errors) > + { > + const char *path = getenv (MODULE_PATH_ENV); > + > + if (path != NULL) > + errors = lt_dlsetsearchpath (path); > + } > + > + /* Load the module. */ > + if (!errors) > + module = lt_dlopenext (argv[1]); > + > + /* Find the entry point. */ > + if (module) > + { > + run = (entrypoint *) lt_dlsym (module, "run"); > + > + /* In principle, run might legitimately be NULL, so > + I don't use run == NULL as an error indicator > + in general. */ > + errormsg = dlerrordup (errormsg); > + if (errormsg != NULL) > + { > + errors = lt_dlclose (module); > + module = NULL; > + } > + } > + else > + errors = 1; > + > + /* Call the entry point function. */ > + if (!errors) > + { > + int result = (*run) (argv[2]); > + if (result < 0) > + errormsg = strdup ("module entry point execution failed"); > + else > + printf ("\t=> %d\n", result); > + } > + > + /* Unload the module, now that we are done with it. */ > + if (!errors) > + errors = lt_dlclose (module); > + > + if (errors) > + { > + /* Diagnose the encountered error. */ > + errormsg = dlerrordup (errormsg); > + > + if (!errormsg) > + { > + fprintf (stderr, "%s: dlerror() failed.\n", argv[0]); > + return EXIT_FAILURE; > + } > + } > + > + /* Finished with ltdl now. */ > + if (!errors) > + if (lt_dlexit () != 0) > + errormsg = dlerrordup (errormsg); I'm not particularly fond of this coding style, where ownership information essentially gets lots once an error occurs in any of the commands. Might be ok for a test like this, but not such a good example for users. lt_dlexit could be warranted even if some error occurred before. Anyway, I won't reject the patch for this. > + if (errormsg) > + { > + fprintf (stderr, "%s: %s.\n", argv[0], errormsg); > + free (errormsg); > + exit (EXIT_FAILURE); > + } > + > + return EXIT_SUCCESS; > +} > + > +/* Be careful to save a copy of the error message, > + since the next API call may overwrite the original. */ > +static char * > +dlerrordup (char *errormsg) > +{ > + char *error = (char *) lt_dlerror (); > + if (error && !errormsg) > + errormsg = strdup (error); > + return errormsg; > +} > +]]) > +if test "$shlibpath_var" = PATH; then This looks wrong; shouldn't it be != here? Otherwise, ... > + $unset shlibpath_var || shlibpath_var= > +fi > +rm $libdir/simple-module.la ... this has only a small chance of succeeding. > +rm $libdir/libsimple-dylib.la > + > +for dir in inst/lib "$libdir"; do > + LT_AT_EXEC_CHECK([./ltdl-loader], [], [stdout], [ignore], > + [$dir/simple-module World]) > + AT_CHECK([grep "Hello, World" stdout], [], [ignore]) > + LT_AT_EXEC_CHECK([./ltdl-loader], [], [stdout], [ignore], > + [$dir/libsimple-dylib World]) > + AT_CHECK([grep "Hello, World" stdout], [], [ignore]) > +done > + > +AT_CLEANUP ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2011-03-04 18:47 ` Ralf Wildenhues @ 2011-03-04 19:00 ` Peter O'Gorman 2011-03-05 16:16 ` Peter O'Gorman 0 siblings, 1 reply; 31+ messages in thread From: Peter O'Gorman @ 2011-03-04 19:00 UTC (permalink / raw) To: Hans Aberg, Guile bug, Ludovic Courtès, Michael Ellis, libtool-patches On 03/04/2011 12:47 PM, Ralf Wildenhues wrote: > [ dropping bug-libtool ] > > Hi Peter, > > * Peter O'Gorman wrote on Fri, Mar 04, 2011 at 07:07:30PM CET: >> Ok? > > A few copyright year bumps are missing. Oh, yeah, will fix. > Some minor nits inline below. >> +AT_SETUP(darwin can lt_dlopen .dylib and .so files) > > Missing m4 quotes (for style only) Ok. >> +AT_CHECK([test "$shared_ext" != "$module_ext" || exit 77], >> + [], [ignore]) > > You can drop arguments two and three here. Ok. >> + int errors = 0; > > Isn't this lacking > LTDL_SET_PRELOADED_SYMBOLS(); > > or was that needed only for static libs (which you've excluded earlier)? It's only needed for static. This bit was copy&pasted from lt_dlopenext.at. >> + if (lt_dlexit () != 0) >> + errormsg = dlerrordup (errormsg); > > I'm not particularly fond of this coding style, where ownership > information essentially gets lots once an error occurs in any > of the commands. Might be ok for a test like this, but not such > a good example for users. lt_dlexit could be warranted even if > some error occurred before. Anyway, I won't reject the patch for > this. Ok, to be honest I didn't even read much of this code, it's from lt_dlopenext.at. > >> +if test "$shlibpath_var" = PATH; then > > This looks wrong; shouldn't it be != here? Otherwise, ... Again, didn't read it!! Will look into it and fix the old test if it's wrong. This bit is not needed or used in the new test anyway, will remove it. Thanks for the quick review. I will adjust and push, probably tomorrow. Peter ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2011-03-04 19:00 ` Peter O'Gorman @ 2011-03-05 16:16 ` Peter O'Gorman 0 siblings, 0 replies; 31+ messages in thread From: Peter O'Gorman @ 2011-03-05 16:16 UTC (permalink / raw) To: Hans Aberg, Guile bug, Ludovic Courtès, Michael Ellis, libtool-patches [-- Attachment #1: Type: text/plain, Size: 343 bytes --] On 03/04/2011 01:00 PM, Peter O'Gorman wrote: > On 03/04/2011 12:47 PM, Ralf Wildenhues wrote: >>> +if test "$shlibpath_var" = PATH; then >> >> This looks wrong; shouldn't it be != here? Otherwise, ... Looking at the original test, the above is correct there - it wants to avoid messing with PATH on Windows. Pushed this. Thanks. Peter [-- Attachment #2: 0001-On-Mac-OS-X-try-.dylib-as-well-as-.so-with-lt_dlopen.patch --] [-- Type: text/x-patch, Size: 10551 bytes --] From e51daabd9975b141ed491f2f49bb340b797a6383 Mon Sep 17 00:00:00 2001 From: Peter O'Gorman <peter@pogma.com> Date: Fri, 4 Mar 2011 14:35:14 -0600 Subject: [PATCH] On Mac OS X try .dylib as well as .so with lt_dlopenext * libltdl/m4/ltdl.m4: Define extra extension if module extension differs from shared lib extension. * libltdl/ltdl.c: Use it. * tests/darwin.at: Test it. * NEWS: Announce it. Reported by Hans Aberg, Michael Ellis, and others. --- ChangeLog | 10 +++ NEWS | 3 + libltdl/ltdl.c | 21 +++++- libltdl/m4/ltdl.m4 | 9 ++- tests/darwin.at | 216 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 5 files changed, 257 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index 7f74eab..528e404 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,13 @@ +2011-03-04 Peter O'Gorman <peter@pogma.com> + + On Mac OS X try .dylib as well as .so with lt_dlopenext + * libltdl/m4/ltdl.m4: Define extra extension if module extension + differs from shared lib extension. + * libltdl/ltdl.c: Use it. + * tests/darwin.at: Test it. + * NEWS: Announce it. + Reported by Hans Aberg, Michael Ellis, and others. + 2011-02-12 Peter O'Gorman <peter@pogma.com> Install ltmain.sh without execute bit set. diff --git a/NEWS b/NEWS index dbad2ae..90d14b7 100644 --- a/NEWS +++ b/NEWS @@ -10,6 +10,9 @@ New in 2.4.2 2011-??-??: git version 2.4.1a, Libtool team: - Initial support for Go, using the gccgo compiler. + - On Mac OS X .dylib is now tried as well as .so with + lt_dlopenext(). + * Bug fixes: - The generic approximation of the command line length limit (when getconf is diff --git a/libltdl/ltdl.c b/libltdl/ltdl.c index be1e4c0..01853e0 100644 --- a/libltdl/ltdl.c +++ b/libltdl/ltdl.c @@ -1,7 +1,7 @@ /* ltdl.c -- system independent dlopen wrapper Copyright (C) 1998, 1999, 2000, 2004, 2005, 2006, - 2007, 2008 Free Software Foundation, Inc. + 2007, 2008, 2011 Free Software Foundation, Inc. Written by Thomas Tanner, 1998 NOTE: The canonical source of this file is maintained with the @@ -80,6 +80,11 @@ static const char libprefix[] = LT_LIBPREFIX; #if defined(LT_MODULE_EXT) static const char shlib_ext[] = LT_MODULE_EXT; #endif +/* If the loadable module suffix is not the same as the linkable + * shared library suffix, this will be defined. */ +#if defined(LT_SHARED_EXT) +static const char shared_ext[] = LT_SHARED_EXT; +#endif #if defined(LT_DLSEARCH_PATH) static const char sys_dlsearch_path[] = LT_DLSEARCH_PATH; #endif @@ -1537,6 +1542,9 @@ has_library_ext (const char *filename) #if defined(LT_MODULE_EXT) || (streq (ext, shlib_ext)) #endif +#if defined(LT_SHARED_EXT) + || (streq (ext, shared_ext)) +#endif )) { return 1; @@ -1682,6 +1690,17 @@ lt_dlopenadvise (const char *filename, lt_dladvise advise) if (handle || ((errors > 0) && !file_not_found ())) return handle; #endif + +#if defined(LT_SHARED_EXT) + /* Try appending SHARED_EXT. */ + LT__SETERRORSTR (saved_error); + errors = try_dlopen (&handle, filename, shared_ext, advise); + + /* As before, if the file was found but loading failed, return now + with the current error message. */ + if (handle || ((errors > 0) && !file_not_found ())) + return handle; +#endif } /* Still here? Then we really did fail to locate any of the file diff --git a/libltdl/m4/ltdl.m4 b/libltdl/m4/ltdl.m4 index 42e07e9..ea76f4d 100644 --- a/libltdl/m4/ltdl.m4 +++ b/libltdl/m4/ltdl.m4 @@ -1,6 +1,6 @@ # ltdl.m4 - Configure ltdl for the target system. -*-Autoconf-*- # -# Copyright (C) 1999-2006, 2007, 2008 Free Software Foundation, Inc. +# Copyright (C) 1999-2006, 2007, 2008, 2011 Free Software Foundation, Inc. # Written by Thomas Tanner, 1999 # # This file is free software; the Free Software Foundation gives @@ -553,12 +553,19 @@ AC_CACHE_CHECK([which extension is used for runtime loadable modules], [ module=yes eval libltdl_cv_shlibext=$shrext_cmds +module=no +eval libltdl_cv_shrext=$shrext_cmds ]) if test -n "$libltdl_cv_shlibext"; then m4_pattern_allow([LT_MODULE_EXT])dnl AC_DEFINE_UNQUOTED([LT_MODULE_EXT], ["$libltdl_cv_shlibext"], [Define to the extension used for runtime loadable modules, say, ".so".]) fi +if test "$libltdl_cv_shrext" != "$libltdl_cv_shlibext"; then + m4_pattern_allow([LT_SHARED_EXT])dnl + AC_DEFINE_UNQUOTED([LT_SHARED_EXT], ["$libltdl_cv_shrext"], + [Define to the shared library suffix, say, ".dylib".]) +fi ])# LT_SYS_MODULE_EXT # Old name: diff --git a/tests/darwin.at b/tests/darwin.at index 4e5034e..b255abe 100644 --- a/tests/darwin.at +++ b/tests/darwin.at @@ -228,3 +228,219 @@ mv stdout expout LT_AT_CONFIGURE([LDFLAGS=-L/there/is/no/dir/here]) AT_CHECK([./libtool --config],[ignore],[expout],[ignore]) AT_CLEANUP + +AT_SETUP([darwin can lt_dlopen .dylib and .so files]) + +AT_KEYWORDS([libltdl dylib]) + +# This test requires shared library support. +AT_CHECK([$LIBTOOL --features | grep 'enable shared libraries' || exit 77], + [], [ignore]) + +eval `$LIBTOOL --config | $EGREP '^shrext_cmds='` + +module=no +eval shared_ext=\"$shrext_cmds\" +module=yes +eval module_ext=\"$shrext_cmds\" + +# Only bother with this test if module extension is different from +# shared extension +AT_CHECK([test "$shared_ext" != "$module_ext" || exit 77]) + +# Skip this test when called from: +# make distcheck DISTCHECK_CONFIGURE_FLAGS=--disable-ltdl-install +AT_CHECK([case $LIBLTDL in #( + */_inst/lib/*) test -f $LIBLTDL || (exit 77) ;; +esac], [], [ignore]) + +prefix=`pwd`/inst +libdir=$prefix/lib +bindir=$prefix/bin +mkdir $prefix $libdir $bindir + +# This code is copied from the Autobook: +# <http://sources.redhat.com/autobook/autobook/autobook_169.html> +# so if it needs changes, be sure to notify the Autobook authors +# about them. + +AT_DATA([simple-module.c], +[[ +#include <stdio.h> + +#ifdef __cplusplus +extern "C" +#endif +int +run (const char *argument) +{ + printf ("Hello, %s!\n", argument); + return 0; +} +]]) + +AT_DATA([ltdl-loader.c], +[[ +#include <stdio.h> +#include <stdlib.h> +#ifndef EXIT_FAILURE +# define EXIT_FAILURE 1 +# define EXIT_SUCCESS 0 +#endif + +#include <limits.h> +#ifndef PATH_MAX +# define PATH_MAX 255 +#endif + +#include <string.h> +#include <ltdl.h> + +#ifndef MODULE_PATH_ENV +# define MODULE_PATH_ENV "MODULE_PATH" +#endif + +typedef int entrypoint (const char *argument); + +/* Save and return a copy of the dlerror() error message, + since the next API call may overwrite the original. */ +static char *dlerrordup (char *errormsg); + +int +main (int argc, const char *argv[]) +{ + char *errormsg = NULL; + lt_dlhandle module = NULL; + entrypoint *run = NULL; + int errors = 0; + + if (argc != 3) + { + fprintf (stderr, "USAGE: main MODULENAME ARGUMENT\n"); + exit (EXIT_FAILURE); + } + + /* Initialise libltdl. */ + errors = lt_dlinit (); + + /* Set the module search path. */ + if (!errors) + { + const char *path = getenv (MODULE_PATH_ENV); + + if (path != NULL) + errors = lt_dlsetsearchpath (path); + } + + /* Load the module. */ + if (!errors) + module = lt_dlopenext (argv[1]); + + /* Find the entry point. */ + if (module) + { + run = (entrypoint *) lt_dlsym (module, "run"); + + /* In principle, run might legitimately be NULL, so + I don't use run == NULL as an error indicator + in general. */ + errormsg = dlerrordup (errormsg); + if (errormsg != NULL) + { + errors = lt_dlclose (module); + module = NULL; + } + } + else + errors = 1; + + /* Call the entry point function. */ + if (!errors) + { + int result = (*run) (argv[2]); + if (result < 0) + errormsg = strdup ("module entry point execution failed"); + else + printf ("\t=> %d\n", result); + } + + /* Unload the module, now that we are done with it. */ + if (!errors) + errors = lt_dlclose (module); + + if (errors) + { + /* Diagnose the encountered error. */ + errormsg = dlerrordup (errormsg); + + if (!errormsg) + { + fprintf (stderr, "%s: dlerror() failed.\n", argv[0]); + return EXIT_FAILURE; + } + } + + /* Finished with ltdl now. */ + if (!errors) + if (lt_dlexit () != 0) + errormsg = dlerrordup (errormsg); + + if (errormsg) + { + fprintf (stderr, "%s: %s.\n", argv[0], errormsg); + free (errormsg); + exit (EXIT_FAILURE); + } + + return EXIT_SUCCESS; +} + +/* Be careful to save a copy of the error message, + since the next API call may overwrite the original. */ +static char * +dlerrordup (char *errormsg) +{ + char *error = (char *) lt_dlerror (); + if (error && !errormsg) + errormsg = strdup (error); + return errormsg; +} +]]) + +: ${LTDLINCL="-I$abs_top_srcdir/libltdl"} +: ${LIBLTDL="$abs_builddir/../libltdl/libltdlc.la"} + +CPPFLAGS="$LTDLINCL $CPPFLAGS" +LDFLAGS="$LDFLAGS -no-undefined" + +AT_CHECK([$LIBTOOL --mode=compile $CC $CPPFLAGS $CFLAGS -c simple-module.c], + [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o simple-module.la ]dnl + [simple-module.lo -rpath $libdir -module -avoid-version], + [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o libsimple-dylib.la ]dnl + [simple-module.lo -rpath $libdir -avoid-version], + [], [ignore], [ignore]) +AT_CHECK([$CC $CPPFLAGS $CFLAGS -c ltdl-loader.c], + [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o ltdl-loader$EXEEXT ]dnl + [ltdl-loader.$OBJEXT -dlopen self $LIBLTDL], + [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=install cp simple-module.la $libdir/simple-module.la], [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=install cp libsimple-dylib.la $libdir/libsimple-dylib.la], [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=clean rm -f simple-module.la], [], [ignore], [ignore]) +AT_CHECK([$LIBTOOL --mode=clean rm -f libsimple-dylib.la], [], [ignore], [ignore]) + +rm $libdir/simple-module.la +rm $libdir/libsimple-dylib.la + +for dir in inst/lib "$libdir"; do + LT_AT_EXEC_CHECK([./ltdl-loader], [], [stdout], [ignore], + [$dir/simple-module World]) + AT_CHECK([grep "Hello, World" stdout], [], [ignore]) + LT_AT_EXEC_CHECK([./ltdl-loader], [], [stdout], [ignore], + [$dir/libsimple-dylib World]) + AT_CHECK([grep "Hello, World" stdout], [], [ignore]) +done + +AT_CLEANUP -- 1.7.3.4 ^ permalink raw reply related [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2011-03-03 19:32 Hans Åberg 2011-03-03 19:56 ` Michael Ellis @ 2011-03-04 3:00 ` Bob Friesenhahn 2011-03-04 3:48 ` Michael Ellis 2011-03-04 9:47 ` Hans Aberg 1 sibling, 2 replies; 31+ messages in thread From: Bob Friesenhahn @ 2011-03-04 3:00 UTC (permalink / raw) To: Hans Åberg; +Cc: Guile bug, Ludovic Courtès, bug-libtool [-- Attachment #1: Type: TEXT/PLAIN, Size: 1284 bytes --] On Thu, 3 Mar 2011, Hans Åberg wrote: > So guile-2.0.0 using libltdl.7.dylib of libtool-2.4, can on Mac OS X > 10.6.6 only open a dynamic library if the name of what it actually > opens ends in .so (say by making a soft link using 'ln -s'); if it > ends in .dylib, it cannot open it, even if the full name is given. > > See > http://lists.gnu.org/archive/html/bug-guile/2011-03/msg00008.html > http://lists.gnu.org/archive/html/guile-devel/2011-03/msg00021.html Are you sure that libltdl from libtool-2.4 is being used? The dtruss trace (from Michael Ellis) at http://lists.gnu.org/archive/html/bug-guile/2011-03/msg00020.html shows insecure accesses more like I would expect from a libtool version suffering from CVE-2009-3736, which is very dangerous under OS X. See http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3736 The recommended portable way to load modules is via a libtool module .la file. It is also recommended to load modules via a full path rather than via a search path because the search path might not be as secure and predicable as you might like. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2011-03-04 3:00 ` Bob Friesenhahn @ 2011-03-04 3:48 ` Michael Ellis 2011-03-04 17:04 ` Ralf Wildenhues 2011-03-04 9:47 ` Hans Aberg 1 sibling, 1 reply; 31+ messages in thread From: Michael Ellis @ 2011-03-04 3:48 UTC (permalink / raw) To: Bob Friesenhahn Cc: Guile bug, Ludovic Courtès, Hans Åberg, bug-libtool On Thu, Mar 3, 2011 at 10:00 PM, Bob Friesenhahn <bfriesen@simple.dallas.tx.us> wrote: > Are you sure that libltdl from libtool-2.4 is being used? The dtruss trace > (from Michael Ellis) at > http://lists.gnu.org/archive/html/bug-guile/2011-03/msg00020.html shows > insecure accesses more like I would expect from a libtool version suffering > from CVE-2009-3736, which is very dangerous under OS X. Thanks for the warning, Bob. It's probably not 2.4 as my GNU tool versions have been mostly installed from macports until very recently. It's a choice I now regret as it's causing me increasing amounts of grief lately. If I install 2.4, do I need to rebuild everything that uses it or will the newer library be picked up at run time? Cheers, Mike ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2011-03-04 3:48 ` Michael Ellis @ 2011-03-04 17:04 ` Ralf Wildenhues 0 siblings, 0 replies; 31+ messages in thread From: Ralf Wildenhues @ 2011-03-04 17:04 UTC (permalink / raw) To: Michael Ellis Cc: Guile bug, bug-libtool, Ludovic Courtès, Hans Åberg, Bob Friesenhahn Hello, * Michael Ellis wrote on Fri, Mar 04, 2011 at 04:48:44AM CET: > If I install 2.4, do I need to rebuild everything that > uses it or will the newer library be picked up at run time? The last incompatible change in libltdl was in Libtool 2.2.6. If you are upgrading from a version older than that, you need to relink. Cheers, Ralf ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2011-03-04 3:00 ` Bob Friesenhahn 2011-03-04 3:48 ` Michael Ellis @ 2011-03-04 9:47 ` Hans Aberg 1 sibling, 0 replies; 31+ messages in thread From: Hans Aberg @ 2011-03-04 9:47 UTC (permalink / raw) To: Bob Friesenhahn; +Cc: Guile bug, Ludovic Courtès, bug-libtool On 4 Mar 2011, at 04:00, Bob Friesenhahn wrote: >> So guile-2.0.0 using libltdl.7.dylib of libtool-2.4, can on Mac OS X 10.6.6 only open a dynamic library if the name of what it actually opens ends in .so (say by making a soft link using 'ln -s'); if it ends in .dylib, it cannot open it, even if the full name is given. >> >> See >> http://lists.gnu.org/archive/html/bug-guile/2011-03/msg00008.html >> http://lists.gnu.org/archive/html/guile-devel/2011-03/msg00021.html > > Are you sure that libltdl from libtool-2.4 is being used? I used that - I made a new clean Mac OS X 10.6.6 installation, everything recompiled. Hans ^ permalink raw reply [flat|nested] 31+ messages in thread
* Mac OS X .dylib not working @ 2010-02-01 14:26 Hans Aberg 2010-02-02 6:42 ` Ralf Wildenhues 0 siblings, 1 reply; 31+ messages in thread From: Hans Aberg @ 2010-02-01 14:26 UTC (permalink / raw) To: bug-libtool; +Cc: bug-guile [I'm not on this list, so please cc me.] 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 --version ltmain.sh (GNU libtool) 2.2.6b guile --version Guile 1.8.7 Hans ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-01 14:26 Hans Aberg @ 2010-02-02 6:42 ` Ralf Wildenhues 2010-02-02 9:08 ` Hans Aberg 0 siblings, 1 reply; 31+ messages in thread From: Ralf Wildenhues @ 2010-02-02 6:42 UTC (permalink / raw) To: Hans Aberg; +Cc: bug-guile, bug-libtool 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-02 6:42 ` Ralf Wildenhues @ 2010-02-02 9:08 ` Hans Aberg 2010-02-02 14:20 ` Ken Raeburn 0 siblings, 1 reply; 31+ messages in thread From: Hans Aberg @ 2010-02-02 9:08 UTC (permalink / raw) To: Ralf Wildenhues; +Cc: bug-guile, bug-libtool 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-02 9:08 ` Hans Aberg @ 2010-02-02 14:20 ` Ken Raeburn 2010-02-02 15:48 ` Hans Aberg 0 siblings, 1 reply; 31+ messages in thread From: Ken Raeburn @ 2010-02-02 14:20 UTC (permalink / raw) To: Hans Aberg; +Cc: bug-guile, Ralf Wildenhues, bug-libtool 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-02 14:20 ` Ken Raeburn @ 2010-02-02 15:48 ` Hans Aberg 2010-02-02 16:52 ` Bob Friesenhahn 0 siblings, 1 reply; 31+ messages in thread From: Hans Aberg @ 2010-02-02 15:48 UTC (permalink / raw) To: Ken Raeburn; +Cc: bug-guile, bug-libtool 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-02 15:48 ` Hans Aberg @ 2010-02-02 16:52 ` Bob Friesenhahn 2010-02-02 17:15 ` Hans Aberg 2010-02-04 12:40 ` Hans Aberg 0 siblings, 2 replies; 31+ messages in thread From: Bob Friesenhahn @ 2010-02-02 16:52 UTC (permalink / raw) To: Hans Aberg; +Cc: bug-guile, Ken Raeburn, bug-libtool 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 bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-02 16:52 ` Bob Friesenhahn @ 2010-02-02 17:15 ` Hans Aberg 2010-02-02 18:01 ` Ludovic Courtès 2010-02-04 12:40 ` Hans Aberg 1 sibling, 1 reply; 31+ messages in thread From: Hans Aberg @ 2010-02-02 17:15 UTC (permalink / raw) To: Bob Friesenhahn; +Cc: bug-guile, Ludovic Courtès, Ken Raeburn, bug-libtool 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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-02 17:15 ` Hans Aberg @ 2010-02-02 18:01 ` Ludovic Courtès 2010-02-03 14:23 ` Ken Raeburn 0 siblings, 1 reply; 31+ messages in thread From: Ludovic Courtès @ 2010-02-02 18:01 UTC (permalink / raw) To: bug-guile; +Cc: bug-libtool Hi, Hans Aberg <haberg@math.su.se> 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 <DE114180-13F6-498C-9E48-9407E5CFBBA7@math.su.se> [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 ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-02 18:01 ` Ludovic Courtès @ 2010-02-03 14:23 ` Ken Raeburn 2010-02-03 15:10 ` Ludovic Courtès 0 siblings, 1 reply; 31+ messages in thread From: Ken Raeburn @ 2010-02-03 14:23 UTC (permalink / raw) To: Ludovic Courtès; +Cc: bug-guile, bug-libtool [Is Hans on one of these lists now? His original message to bug-guile said not and asked to be cc'ed.] On Feb 2, 2010, at 13:01, Ludovic Courtès wrote: > The Guile manually specifically tells that FNAME should not contain an > extension. That could be unfortunate, since it means that unlike other Mac applications, a Guile application would not be able to customize its plugin names to use Foo.quuxplugin type names. Guile apps would be limited to a hardcoded set of suffixes then, right? > 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’. Current versions of Mac OS X can load shared libraries (.dylib) as well as the bundle format that seems to have been the original plugin form (.so, .bundle, ...). So in practice, assuming you can dlopen and dlclose a shared library works pretty well, though I gather it might not have worked as well in earlier releases. But we should also support the format(s) intended for plugin modules as well, and the naming conventions (which appear to be somewhat varied, and less consistent than on other OSes). At least, that's my impression; I'm not an expert in that area of the OS, I've just read some of the docs... Ken ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-03 14:23 ` Ken Raeburn @ 2010-02-03 15:10 ` Ludovic Courtès 0 siblings, 0 replies; 31+ messages in thread From: Ludovic Courtès @ 2010-02-03 15:10 UTC (permalink / raw) To: Ken Raeburn; +Cc: bug-guile, bug-libtool Hi, Ken Raeburn <raeburn@raeburn.org> writes: > [Is Hans on one of these lists now? His original message to bug-guile > said not and asked to be cc'ed.] We might have lost him then. ;-) > On Feb 2, 2010, at 13:01, Ludovic Courtès wrote: >> The Guile manually specifically tells that FNAME should not contain >> an extension. > > That could be unfortunate, since it means that unlike other Mac > applications, a Guile application would not be able to customize its > plugin names to use Foo.quuxplugin type names. Guile apps would be > limited to a hardcoded set of suffixes then, right? Guile doesn’t modify FNAME, it just passes it on to ‘lt_dlopenext ()’. >> 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’. > > Current versions of Mac OS X can load shared libraries (.dylib) as > well as the bundle format that seems to have been the original plugin > form (.so, .bundle, ...). So in practice, assuming you can dlopen and > dlclose a shared library works pretty well, though I gather it might > not have worked as well in earlier releases. OK. > But we should also support the format(s) intended for plugin modules > as well, and the naming conventions (which appear to be somewhat > varied, and less consistent than on other OSes). Since libguile-srfi-srfi-1 is intended both to be dlopened and linked directly against, we’d need to link it twice, once with ‘-module’ and another one to create the shared library. I can’t imagine myself tweaking the build system in non-trivial ways to accommodate old versions of OS X, though... Thanks, Ludo’. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-02 16:52 ` Bob Friesenhahn 2010-02-02 17:15 ` Hans Aberg @ 2010-02-04 12:40 ` Hans Aberg 2010-02-04 13:49 ` Peter O'Gorman 1 sibling, 1 reply; 31+ messages in thread From: Hans Aberg @ 2010-02-04 12:40 UTC (permalink / raw) To: Bob Friesenhahn; +Cc: bug-guile, Ken Raeburn, bug-libtool On 2 Feb 2010, at 17:52, Bob Friesenhahn wrote: > Under OS-X (Leopard and later), the 'dtruss' program can be used to > see what is really going on. While at it, I found another problem involving libltdl.7.dylib, guile-1.8.7 and lilypond 2.13.7: When upgrading guile using libtool-2.2.6b, lilypond broke, the one which is in an Application distribution: /Applications/LilyPond.app/Contents/Resources/bin/guile It has its own /Applications/LilyPond.app/Contents/Resources/lib/libltdl.7.dylib However, dtruss shows that segmentation fault is caused when calling /usr/local/lib/libltdl.7.dylib When I move this to another name, then lilypond works, but dtruss now shows that it calls /usr/lib/libltdl.7.dylib So it seems lilypond never calls its own libltdl.7.dylib. The problem here, though, is the combination of incompatible versions of libltdl.7.dylib in combination with a library search path. If they really are incompatible, there seems to be no point in having a searchpath. I think that gcc on Mac OS X makes hardcoded full paths for libraries. So libtool would then implement its own library search paths. Also, it seems having no problem open .dylib files here. Hans ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-04 12:40 ` Hans Aberg @ 2010-02-04 13:49 ` Peter O'Gorman 2010-02-04 15:21 ` Hans Aberg 0 siblings, 1 reply; 31+ messages in thread From: Peter O'Gorman @ 2010-02-04 13:49 UTC (permalink / raw) To: Hans Aberg; +Cc: bug-guile, Ken Raeburn, bug-libtool On Thu, Feb 04, 2010 at 01:40:07PM +0100, Hans Aberg wrote: > On 2 Feb 2010, at 17:52, Bob Friesenhahn wrote: > >> Under OS-X (Leopard and later), the 'dtruss' program can be used to >> see what is really going on. > > While at it, I found another problem involving libltdl.7.dylib, > guile-1.8.7 and lilypond 2.13.7: > > When upgrading guile using libtool-2.2.6b, lilypond broke, the one which > is in an Application distribution: > /Applications/LilyPond.app/Contents/Resources/bin/guile > It has its own > /Applications/LilyPond.app/Contents/Resources/lib/libltdl.7.dylib > > However, dtruss shows that segmentation fault is caused when calling > /usr/local/lib/libltdl.7.dylib > > When I move this to another name, then lilypond works, but dtruss now > shows that it calls > /usr/lib/libltdl.7.dylib Sorry, I missed most of this thread as I was travelling. What does otool -L /Applications/LilyPond.app/Contents/Resources/bin/guile say? Which libltdl.7.dylib does it list? If you run lilypond with DYLD_PRINT_LIBRARIES=1 set in the environment does more than one copy of libltdl.7.dylib get loaded? This sounds like a packaging bug to me though, you can probably fix it with use of install_name_tool(1). As for your earlier questions about .so and .dylib - On Mac OS X 10.0 and earlier, there was no way to load MH_DYLIB type files (usually .dylib extensions) at runtime. API was introduced to allow this in 10.1, and dlopen() was added in 10.3, rewritten in 10.4 and dlclose() actually removes the image in 10.5, prior to that only files of MH_BUNDLE type could be unloaded. When libtool support for Mac OS X was added, there was no way to load .dylib files, not much software had any knowledge of Mac OS X, and quite a lot of things had hardcoded ".so" when loading files at runtime, so to accomodate this, .so was chosen as the extension when creating loadable modules (MH_BUNDLE) and .dylib when creating MH_DYLIB. Changing this now would cause far too many problems. So, long story short, ltld looks for ".so" because that is the extension used for loadable modules. Guile wants to use its loadable modules as input to ld, this is not portable to ancient Mac OS X, nor ancient Net BSD, and possibly other systems, however it seems unlikly to be a major issue. I think that covers most of the thread, but I admit to now reading all of it. Peter -- Peter O'Gorman http://pogma.com ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-04 13:49 ` Peter O'Gorman @ 2010-02-04 15:21 ` Hans Aberg 2010-02-04 15:34 ` Peter O'Gorman 0 siblings, 1 reply; 31+ messages in thread From: Hans Aberg @ 2010-02-04 15:21 UTC (permalink / raw) To: Peter O'Gorman; +Cc: bug-guile, Ken Raeburn, bug-libtool, Bob Friesenhahn On 4 Feb 2010, at 14:49, Peter O'Gorman wrote: > What does otool -L > /Applications/LilyPond.app/Contents/Resources/bin/guile say? Which > libltdl.7.dylib does it list? See below. They differ: libltdl.7.dylib current versions 10.0.0 and 10.1.0. > If you run lilypond with DYLD_PRINT_LIBRARIES=1 set in the environment > does more than one copy of libltdl.7.dylib get loaded? It just tries to load the one in /usr/local/lib/, which causes segmentation fault. > This sounds like a packaging bug to me though, ... Part if it, at least. There is no point searching for incompatible libraries. > ...you can probably fix it > with use of install_name_tool(1). I can pass it on - I'm not a LilyPond developer. > As for your earlier questions about .so and .dylib - On Mac OS X 10.0 > and earlier, there was no way to load MH_DYLIB type files (usually > .dylib extensions) at runtime. API was introduced to allow this in > 10.1, > and dlopen() was added in 10.3, rewritten in 10.4 and dlclose() > actually > removes the image in 10.5, prior to that only files of MH_BUNDLE type > could be unloaded. > > When libtool support for Mac OS X was added, there was no way to load > .dylib files, not much software had any knowledge of Mac OS X, and > quite > a lot of things had hardcoded ".so" when loading files at runtime, > so to > accomodate this, .so was chosen as the extension when creating > loadable > modules (MH_BUNDLE) and .dylib when creating MH_DYLIB. Changing > this now would cause far too many problems. Not really: 10.4 and earlier are obsolete, and 10.5 is becoming. On 10.5, just ordinary load is fine. So just add .dylib to the list of searches. > So, long story short, ltld looks for ".so" because that is the > extension > used for loadable modules. Well, that is not a part of the UNIX standard, and therefore not POSIX, which is nowadays a subset. > Guile wants to use its loadable modules as > input to ld, this is not portable to ancient Mac OS X, nor ancient Net > BSD, and possibly other systems, however it seems unlikly to be a > major > issue. > > I think that covers most of the thread, but I admit to now reading all > of it. If it can't load .dylib files, which now is the normal use, that is a bit confusing. Hans ---- # otool -L /Applications/LilyPond.app/Contents/Resources/bin/guile /Applications/LilyPond.app/Contents/Resources/bin/guile: @executable_path/../lib//libguile.17.dylib (compatibility version 21.0.0, current version 21.1.0) @executable_path/../lib//libintl.8.dylib (compatibility version 9.0.0, current version 9.0.0) /usr/lib/libiconv.2.dylib (compatibility version 5.0.0, current version 5.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 71.1.3) @executable_path/../lib//libgmp.3.dylib (compatibility version 8.0.0, current version 8.1.0) @executable_path/../lib//libltdl.7.dylib (compatibility version 10.0.0, current version 10.0.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 47.1.0) # otool -L /usr/local/bin/guile /usr/local/bin/guile: /usr/local/lib/libguile.17.dylib (compatibility version 21.0.0, current version 21.1.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/local/lib/libintl.8.dylib (compatibility version 9.0.0, current version 9.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /usr/local/lib/libgmp.3.dylib (compatibility version 9.0.0, current version 9.0.0) /usr/local/lib/libltdl.7.dylib (compatibility version 10.0.0, current version 10.1.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) ---- $ lilypond empty.ly dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/lilypond dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libintl.8.dylib dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libguile.17.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libgmp.3.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libpangoft2-1.0.0.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libpango-1.0.0.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libfreetype.6.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libfontconfig.1.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libgobject-2.0.0.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libgmodule-2.0.0.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libglib-2.0.0.dylib dyld: loaded: /usr/lib/libstdc++.6.dylib dyld: loaded: /usr/lib/libgcc_s.1.dylib dyld: loaded: /usr/lib/libmx.A.dylib dyld: loaded: /usr/lib/libiconv.2.dylib dyld: loaded: /System/Library/Frameworks/CoreFoundation.framework/ Versions/A/CoreFoundation dyld: loaded: /usr/lib/system/libmathCommon.A.dylib dyld: loaded: /usr/lib/libicucore.A.dylib dyld: loaded: /usr/lib/libobjc.A.dylib dyld: loaded: /usr/lib/libauto.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libltdl.7.dylib dyld: loaded: /usr/lib/libz.1.dylib dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ lib//libexpat.1.dylib dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/ Carbon dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/CarbonSound.framework/Versions/A/CarbonSound dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/CommonPanels.framework/Versions/A/CommonPanels dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/Help.framework/Versions/A/Help dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/HIToolbox.framework/Versions/A/HIToolbox dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/ImageCapture.framework/Versions/A/ImageCapture dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/Ink.framework/Versions/A/Ink dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/NavigationServices.framework/Versions/A/NavigationServices dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/OpenScripting.framework/Versions/A/OpenScripting dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/Print.framework/Versions/A/Print dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/SecurityHI.framework/Versions/A/SecurityHI dyld: loaded: /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/ApplicationServices dyld: loaded: /System/Library/Frameworks/CoreServices.framework/ Versions/A/CoreServices dyld: loaded: /System/Library/Frameworks/CoreAudio.framework/Versions/ A/CoreAudio dyld: loaded: /System/Library/Frameworks/CoreServices.framework/ Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore dyld: loaded: /System/Library/Frameworks/CoreServices.framework/ Versions/A/Frameworks/CFNetwork.framework/Versions/A/CFNetwork dyld: loaded: /System/Library/Frameworks/CoreServices.framework/ Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata dyld: loaded: /System/Library/Frameworks/CoreServices.framework/ Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices dyld: loaded: /System/Library/Frameworks/CoreServices.framework/ Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit dyld: loaded: /System/Library/Frameworks/CoreServices.framework/ Versions/A/Frameworks/AE.framework/Versions/A/AE dyld: loaded: /System/Library/Frameworks/CoreServices.framework/ Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices dyld: loaded: /System/Library/Frameworks/CoreServices.framework/ Versions/A/Frameworks/DictionaryServices.framework/Versions/A/ DictionaryServices dyld: loaded: /System/Library/Frameworks/IOKit.framework/Versions/A/ IOKit dyld: loaded: /System/Library/Frameworks/DiskArbitration.framework/ Versions/A/DiskArbitration dyld: loaded: /usr/lib/libbsm.dylib dyld: loaded: /System/Library/Frameworks/Security.framework/Versions/A/ Security dyld: loaded: /System/Library/Frameworks/SystemConfiguration.framework/ Versions/A/SystemConfiguration dyld: loaded: /usr/lib/libsqlite3.0.dylib dyld: loaded: /usr/lib/libresolv.9.dylib dyld: loaded: /usr/lib/libxml2.2.dylib dyld: loaded: /usr/lib/libxslt.1.dylib dyld: loaded: /System/Library/Frameworks/Foundation.framework/Versions/ C/Foundation dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ATS.framework/Versions/A/ATS dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ColorSync.framework/Versions/A/ColorSync dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/CoreText.framework/Versions/A/CoreText dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/ImageIO dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/QD.framework/Versions/A/QD dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/ SpeechSynthesis dyld: loaded: /usr/lib/libcrypto.0.9.7.dylib dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/ A/Accelerate dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/ A/Frameworks/vImage.framework/Versions/A/vImage dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/ A/Frameworks/vecLib.framework/Versions/A/vecLib dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/ A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/ A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/ A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib dyld: loaded: /System/Library/Frameworks/Accelerate.framework/Versions/ A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libJPEG.dylib dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libTIFF.dylib dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libGIF.dylib dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libPng.dylib dyld: loaded: /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/ImageIO.framework/Versions/A/Resources/ libRadiance.dylib dyld: loaded: /usr/lib/libcups.2.dylib dyld: loaded: /System/Library/Frameworks/Kerberos.framework/Versions/A/ Kerberos dyld: loaded: /System/Library/PrivateFrameworks/CoreUI.framework/ Versions/A/CoreUI dyld: loaded: /System/Library/Frameworks/QuartzCore.framework/Versions/ A/QuartzCore dyld: loaded: /System/Library/PrivateFrameworks/ DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/ OpenGL dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/ Libraries/libGLImage.dylib dyld: loaded: /usr/lib/libffi.dylib dyld: loaded: /System/Library/Frameworks/CoreVideo.framework/Versions/ A/CoreVideo dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/ Libraries/libGLU.dylib dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/ Libraries/libGL.dylib dyld: loaded: /System/Library/Frameworks/OpenGL.framework/Versions/A/ Libraries/libGLProgrammability.dylib dyld: loaded: /System/Library/PrivateFrameworks/ InstallServer.framework/Versions/A/InstallServer GNU LilyPond 2.13.7 dyld: loaded: /usr/local/lib/libguile-srfi-srfi-1-v-3.3.dylib dyld: loaded: /usr/local/lib/libguile.17.dylib dyld: loaded: /usr/local/lib/libintl.8.dylib dyld: loaded: /usr/local/lib/libgmp.3.dylib dyld: loaded: /usr/local/lib/libltdl.7.dylib Segmentation fault ---- ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-04 15:21 ` Hans Aberg @ 2010-02-04 15:34 ` Peter O'Gorman 2010-02-04 16:52 ` Hans Aberg 2010-02-04 16:58 ` Hans Aberg 0 siblings, 2 replies; 31+ messages in thread From: Peter O'Gorman @ 2010-02-04 15:34 UTC (permalink / raw) To: Hans Aberg; +Cc: bug-guile, Ken Raeburn, bug-libtool, Bob Friesenhahn On Thu, Feb 04, 2010 at 04:21:27PM +0100, Hans Aberg wrote: >> When libtool support for Mac OS X was added, there was no way to load >> .dylib files, not much software had any knowledge of Mac OS X, and >> quite >> a lot of things had hardcoded ".so" when loading files at runtime, so >> to >> accomodate this, .so was chosen as the extension when creating >> loadable >> modules (MH_BUNDLE) and .dylib when creating MH_DYLIB. Changing >> this now would cause far too many problems. > > Not really: 10.4 and earlier are obsolete, and 10.5 is becoming. On > 10.5, just ordinary load is fine. 10.4 and earlier are not obsolete, sorry. >> So, long story short, ltld looks for ".so" because that is the >> extension >> used for loadable modules. > > Well, that is not a part of the UNIX standard, and therefore not POSIX, > which is nowadays a subset. Which part of POSIX standardizes library extensions? > ---- > $ lilypond empty.ly > dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ > lib//libintl.8.dylib > dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ > lib//libguile.17.dylib > dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ > lib//libltdl.7.dylib > GNU LilyPond 2.13.7 > dyld: loaded: /usr/local/lib/libguile-srfi-srfi-1-v-3.3.dylib > dyld: loaded: /usr/local/lib/libguile.17.dylib > dyld: loaded: /usr/local/lib/libintl.8.dylib > dyld: loaded: /usr/local/lib/libgmp.3.dylib > dyld: loaded: /usr/local/lib/libltdl.7.dylib > Segmentation fault So lilypond starts up fine, but guile's first dlopen() for libguile-srfi-srfi-1-v-3.3 causes the library in /usr/local/lib to be loaded (and its dependent libraries, including another libguile, libintl, and libltdl). Ensuring that the search path is correct would fix this problem, look at setting the LTDL_LIBRARY_PATH environment variable, perhaps? Anyway, I am convinced that this is a packaging bug. Peter -- Peter O'Gorman http://pogma.com ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-04 15:34 ` Peter O'Gorman @ 2010-02-04 16:52 ` Hans Aberg 2010-02-04 16:58 ` Hans Aberg 1 sibling, 0 replies; 31+ messages in thread From: Hans Aberg @ 2010-02-04 16:52 UTC (permalink / raw) To: Peter O'Gorman; +Cc: bug-guile, Ken Raeburn, bug-libtool On 4 Feb 2010, at 16:34, Peter O'Gorman wrote: >> Not really: 10.4 and earlier are obsolete, and 10.5 is becoming. On >> 10.5, just ordinary load is fine. > 10.4 and earlier are not obsolete, sorry. The only computers that can't run 10.4 are G3 and they are really to slow. At least the one I installed it on. !0.5 runs fine also on a G4 350 Ghz I tried it on. >>> So, long story short, ltld looks for ".so" because that is the >>> extension >>> used for loadable modules. >> >> Well, that is not a part of the UNIX standard, and therefore not >> POSIX, >> which is nowadays a subset. > > Which part of POSIX standardizes library extensions? None. There is some mentioning about c99 and make about .c, .f and .o files, but really no requirements. You can use those for portability reasons. Or at least that is what they say one the UNIX standardization list. >> ---- >> $ lilypond empty.ly >> dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ >> lib//libintl.8.dylib >> dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ >> lib//libguile.17.dylib >> dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ >> lib//libltdl.7.dylib >> GNU LilyPond 2.13.7 >> dyld: loaded: /usr/local/lib/libguile-srfi-srfi-1-v-3.3.dylib >> dyld: loaded: /usr/local/lib/libguile.17.dylib >> dyld: loaded: /usr/local/lib/libintl.8.dylib >> dyld: loaded: /usr/local/lib/libgmp.3.dylib >> dyld: loaded: /usr/local/lib/libltdl.7.dylib >> Segmentation fault > > So lilypond starts up fine, but guile's first dlopen() for > libguile-srfi-srfi-1-v-3.3 causes the library in /usr/local/lib to be > loaded (and its dependent libraries, including another libguile, > libintl, and libltdl). Ensuring that the search path is correct would > fix this problem, look at setting the LTDL_LIBRARY_PATH environment > variable, perhaps? Does what flags does libtool use when compiling dynamic libraries? One can compile with name lookup table and direct jump table. The former, it seems would not break if version differ, if they contain the same function. > Anyway, I am convinced that this is a packaging bug. They will probably have to do something to make sure their own libraries are called - that's their bug. Hans ^ permalink raw reply [flat|nested] 31+ messages in thread
* Re: Mac OS X .dylib not working 2010-02-04 15:34 ` Peter O'Gorman 2010-02-04 16:52 ` Hans Aberg @ 2010-02-04 16:58 ` Hans Aberg 1 sibling, 0 replies; 31+ messages in thread From: Hans Aberg @ 2010-02-04 16:58 UTC (permalink / raw) To: Peter O'Gorman; +Cc: bug-guile, Ken Raeburn, bug-libtool On 4 Feb 2010, at 16:34, Peter O'Gorman wrote: >> ---- >> $ lilypond empty.ly >> dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ >> lib//libintl.8.dylib >> dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ >> lib//libguile.17.dylib >> dyld: loaded: /Applications/LilyPond.app/Contents/Resources/bin/../ >> lib//libltdl.7.dylib >> GNU LilyPond 2.13.7 >> dyld: loaded: /usr/local/lib/libguile-srfi-srfi-1-v-3.3.dylib >> dyld: loaded: /usr/local/lib/libguile.17.dylib >> dyld: loaded: /usr/local/lib/libintl.8.dylib >> dyld: loaded: /usr/local/lib/libgmp.3.dylib >> dyld: loaded: /usr/local/lib/libltdl.7.dylib >> Segmentation fault > > So lilypond starts up fine, but guile's first dlopen() for > libguile-srfi-srfi-1-v-3.3 causes the library in /usr/local/lib to be > loaded (and its dependent libraries, including another libguile, > libintl, and libltdl). Ensuring that the search path is correct would > fix this problem, look at setting the LTDL_LIBRARY_PATH environment > variable, perhaps? Sorry, I should have answered this one: the variable isn't set, and exporting it to say LTDL_LIBRARY_PATH=/Applications/LilyPond.app/Contents/Resources/lib before starting 'lilypond' does not change the behavior. Hans ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2011-03-05 16:16 UTC | newest] Thread overview: 31+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-03-03 19:53 Mac OS X .dylib not working Hans Aberg -- strict thread matches above, loose matches on Subject: below -- 2011-03-03 19:32 Hans Åberg 2011-03-03 19:56 ` Michael Ellis 2011-03-04 2:59 ` Peter O'Gorman 2011-03-04 3:41 ` Michael Ellis 2011-03-04 8:59 ` Andy Wingo 2011-03-04 9:44 ` Hans Aberg 2011-03-04 18:07 ` Peter O'Gorman 2011-03-04 18:47 ` Ralf Wildenhues 2011-03-04 19:00 ` Peter O'Gorman 2011-03-05 16:16 ` Peter O'Gorman 2011-03-04 3:00 ` Bob Friesenhahn 2011-03-04 3:48 ` Michael Ellis 2011-03-04 17:04 ` Ralf Wildenhues 2011-03-04 9:47 ` Hans Aberg 2010-02-01 14:26 Hans Aberg 2010-02-02 6:42 ` Ralf Wildenhues 2010-02-02 9:08 ` Hans Aberg 2010-02-02 14:20 ` Ken Raeburn 2010-02-02 15:48 ` Hans Aberg 2010-02-02 16:52 ` Bob Friesenhahn 2010-02-02 17:15 ` Hans Aberg 2010-02-02 18:01 ` Ludovic Courtès 2010-02-03 14:23 ` Ken Raeburn 2010-02-03 15:10 ` Ludovic Courtès 2010-02-04 12:40 ` Hans Aberg 2010-02-04 13:49 ` Peter O'Gorman 2010-02-04 15:21 ` Hans Aberg 2010-02-04 15:34 ` Peter O'Gorman 2010-02-04 16:52 ` Hans Aberg 2010-02-04 16:58 ` Hans Aberg
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).