(ITS#5602) Windows ODBC library libodbc32 not found by configure

[mail_ben_schmidt@yahoo.com.au]

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.