Mac OS X .dylib not working

Mac OS X .dylib not working

[Hans Aberg]

[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

Re: Mac OS X .dylib not working

[Ralf Wildenhues]

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

[Hans Aberg]

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

Re: Mac OS X .dylib not working

[Ken Raeburn]

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

[Hans Aberg]

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

[Bob Friesenhahn]

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/

Re: Mac OS X .dylib not working

[Hans Aberg]

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

[Ludovic Courtès]

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

Re: Mac OS X .dylib not working

[Ken Raeburn]

[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

Re: Mac OS X .dylib not working

[Ludovic Courtès]

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

Re: Mac OS X .dylib not working

[Hans Aberg]

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

Re: Mac OS X .dylib not working

[Peter O'Gorman]

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

Re: Mac OS X .dylib not working

[Hans Aberg]

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

Re: Mac OS X .dylib not working

[Peter O'Gorman]

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

Re: Mac OS X .dylib not working

[Hans Aberg]

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

Re: Mac OS X .dylib not working

[Hans Aberg]

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

Mac OS X .dylib not working

[Hans Åberg]

[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

Re: Mac OS X .dylib not working

[Michael Ellis]

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

Re: Mac OS X .dylib not working

[Peter O'Gorman]

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

Re: Mac OS X .dylib not working

[Michael Ellis]

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

Re: Mac OS X .dylib not working

[Andy Wingo]

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/

Re: Mac OS X .dylib not working

[Hans Aberg]

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

Re: Mac OS X .dylib not working

[Peter O'Gorman]

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

Re: Mac OS X .dylib not working

[Ralf Wildenhues]

[ 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

Re: Mac OS X .dylib not working

[Peter O'Gorman]

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

Re: Mac OS X .dylib not working

[Peter O'Gorman]

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

Re: Mac OS X .dylib not working

[Bob Friesenhahn]

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

Re: Mac OS X .dylib not working

[Michael Ellis]

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

Re: Mac OS X .dylib not working

[Ralf Wildenhues]

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

Re: Mac OS X .dylib not working

[Hans Aberg]

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

Mac OS X .dylib not working

[Hans Aberg]

[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