On Feb 3, 2007, at 11:36 AM, Daniel Johnson wrote:

> On Feb 2, 2007, at 11:12 PM, Dan Fandrich wrote:
>
>> On Fri, Feb 02, 2007 at 09:00:00PM -0500, Daniel Johnson wrote:
>>> So curl needs to pass either /System/Library/Frameworks/
>>> LDAP.framework/Versions/A/LDAP (the actual library) or simply
>>> libldap.dylib to dlopen. If no "/" appears in the path, dlopen will
>>> automatically search /usr/lib. You can alternatively link directly
>>> with the standard -lldap.
>>
>> Ok, so no libraries use the .so extension? If that's the case, then
>> libtool is getting it wrong and $std_shrext should be .dylib.
>> But, the
>> contents of shrext_cmds (test .$module = .yes && echo .so ||
>> echo .dylib)
>> implies otherwise.

I finally figured out what was happening here. The problem is that
while $std_shrext gets set properly in the libtool tool itself, it
does NOT get propagated into configure. So it is necessary to use
$shrext_cmds instead. This patch works on Mac OS X and should work
for any recent libtool on other platforms. I left the other options
in since I don't know if they're needed for older versions.

Index: acinclude.m4
===================================================================
RCS file: /cvsroot/curl/curl/acinclude.m4,v
retrieving revision 1.120
diff -u -r1.120 acinclude.m4
--- acinclude.m4 22 Mar 2007 18:59:14 -0000 1.120
+++ acinclude.m4 25 Mar 2007 19:07:09 -0000
@@ -1861,6 +1861,7 @@
AC_MSG_CHECKING([name of dynamic library $2])
dnl The shared library extension variable name changes from version to
dnl version of libtool. Try a few names then just set one statically.
+test -z "$shared_ext" && eval shared_ext=\"$shrext_cmds\"
test -z "$shared_ext" && shared_ext="$std_shrext"
test -z "$shared_ext" && shared_ext="$shrext"
test -z "$shared_ext" && shared_ext=".so"
Received on 2007-03-25