[Date Prev][Date Next]
(ITS#5602) Windows ODBC library libodbc32 not found by configure
Full_Name: Ben Schmidt
OS: MinGW32, Mac OS X
Submission from: (NULL) (18.104.22.168)
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 @@
/* 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 ();*/
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.