Full_Name: Ben Schmidt Version: 2.4.10 OS: MinGW32, Mac OS X URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.168.9.190)

My precise situation is, I am sure, a very uncommon scenario. However, it may affect other building methods as well, and an appropriate fix I am sure could help a few users.

Here's what I have been doing (please try not to laugh!): I have been cross-compiling OpenLDAP on Mac OS X for MinGW32, including the SQL backend. I have found two issues related to the configuration/build process.

I am afraid I really have no knowledge of GNU autoconf, so I will describe the problem and my fixes, but with no pretense that they are appropriate for applying to the code. I will suggest an appropriate way to fix it, but will have to leave that work to another developer.

This is the first.

On Windows/MinGW, the ODBC library is not libodbc.a, but libodbc32.a. Furthermore, it seems the way function names are mangled on that platform includes their stack frame size: the symbol for SQLDriverConnect which configure tests for is _SQLDriverConnect@32.

I got around this by manually changing -lodbc to -lodbc32 in configure and then further patching it as follows:

diff -ru --exclude=Makefile openldap-2.4.10/configure openldap/configure --- openldap-2.4.10/configure 2008-02-12 10:36:45.000000000 +1100 +++ openldap/configure 2008-06-28 19:36:36.000000000 +1000 @@ -32018,11 +32018,14 @@ #endif /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ -char SQLDriverConnect (); +/*char SQLDriverConnect ();*/ +#include <windows.h> +#include <sqlext.h> int main () { -SQLDriverConnect (); +/*SQLDriverConnect ();*/ +SQLDriverConnect (0,0,0,0,0,0,0,0); ; return 0; }

This pulls in the appropriate headers for configure to find and use _SQLDriverConect@32 in libodbc32. I got part of the idea from another user's post I found on the Net, but a quick search of your issue tracker didn't show it up, so I am reporting it now.

A more appropriate fix would be to change configure.in so that there are three checks for ODBC: one in libiodbc, one in libodbc and one in libodbc32, which is Windows specific, pulling in windows.h and sqlext.h before looking for the symbol with 8 arguments. I guess this would probably involve a more customised macro in configure.in. If that is too much trouble, perhaps the value for the ODBC library could just be assumed if configure can detect a Windows build.