On Fri, Feb 02, 2007 at 04:24:09PM -0500, Daniel Johnson wrote:
> While the recent change to acinclude.m4 cleaned things up, configure
> is still generating the wrong file names:
>
> checking name of dynamic library ldap... libldap.so
> checking name of dynamic library lber... liblber.so
>
> On Darwin, those should be libldap.dylib and liblber.dylib.
> Unfortunately, Darwin distinguishes between loadable modules
> (normally named *.so) and shared libraries (named *.dylib). Only
> dylibs can be linked to, but either can be dlopened. Libtool is
> returning .so since that's what is usually used for modules, but in
> this case it's wrong because we're talking about real libraries.

I noticed that, but I haven't had a chance to get on to an OS X system
to figure out what's going on. Unfortunately, the dynamic library
detection macros rely on the use of undocumented internal libtool variables,
so it's tricky business. In this case, I suspect the $std_shrext variable
is not being set for OS X, while the original $shrext_cmds was.

> In addition, those files are actually symlinks to the same file: /
> System/Library/Frameworks/LDAP.framework/Versions/A/LDAP which has no
> extension at all but is a genuine shared library.

What is the name of the LDAP library that curl links against? How about the
dynamic version used at run time? Are they both symlinks to the same 'LDAP'
file?

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved