Address Windows build errors, most config-dependent. #568

ucko · 2024-05-30T14:35:49Z

In the absence of an external SQLGetPrivateProfileString, fail the build only when expecting to use an external driver manager, and expose tds_SQLGetPrivateProfileString to the odbc "connect" unit test. Don't let that test attempt to use SQLGetPrivateProfileStringW even in Unicode builds.
src/odbc/win*.c: Accommodate static builds, with no hinstFreeTDS; in particular, never attempt to show FreeTDS dialog boxes there.
src/utils/unittests/challenge.c: #include <freetds/sysdep_private.h>
to ensure the availability of strcasecmp.

Split from #555.

* In the absence of an external SQLGetPrivateProfileString, fail the build only when expecting to use an external driver manager, and expose tds_SQLGetPrivateProfileString to the odbc "connect" unit test. Don't let that test attempt to use SQLGetPrivateProfileStringW even in Unicode builds. * src/odbc/win*.c: Accommodate static builds, with no hinstFreeTDS; in particular, never attempt to show FreeTDS dialog boxes there. * src/utils/unittests/challenge.c: #include <freetds/sysdep_private.h> to ensure the availability of strcasecmp. Signed-off-by: Aaron M. Ucko <[email protected]>

freddy77 · 2024-06-01T08:55:23Z

src/odbc/connectparams.c

@@ -556,7 +560,7 @@ odbc_build_connect_string(TDS_ERRS *errs, TDS_PARSED_PARAM *params, char **out)

 #if !HAVE_SQLGETPRIVATEPROFILESTRING

-#ifdef _WIN32
+#if defined(_WIN32)  &&  !defined(TDS_NO_DM)


Personally I would avoid this, Windows has a standard driver manager which should be used

ucko · 2024-06-03T15:57:21Z

I acknowledge that bypassing Windows' native DM is unconventional, but it's logistically simpler to use driverless mode everywhere than to arrange to link this API's tests directly against it only in the absence of a system DM. (The C++ Toolkit's build system covers bundled projects itself rather than using their own build systems.) I also seem to recall that the system DM insisted on sticking to drivers that had been registered system-wide, but perhaps that's not actually a problem, at least nowadays.

freddy77 · 2024-06-03T17:06:17Z

Reasonable.

About the connect.c test... does it make sense to execute that part of the test that requires get_entry and so currently system SQLGetPrivateProfileString? It requires the driver to be registered as FreeTDS (see DRIVER=FreeTDS;SERVER=%s;UID=%s;PWD=%s;DATABASE=%s; connection string) which is only implemented by Driver Manager.

UPDATE: other parts of the connect.c test use DRIVER too. However it's still easier to disable this part if a driver manager is not used.

ucko · 2024-06-17T19:00:54Z

AFAICT, that part of the test does actually succeed with this change in place, at least if I point the test at appropriate freetds.conf and odbc.ini files. (I know there's logic to bypass that part when unable to look up the server name via get_entry, but it gets past that logic and proceeds with the remainder of that part.)

src/utils/unittests/challenge.c

src/odbc/winlogin.c

src/odbc/winsetup.c

freddy77 · 2024-06-18T08:09:56Z

src/odbc/unittests/connect.c

+#if !HAVE_SQLGETPRIVATEPROFILESTRING
+#  define SQLGetPrivateProfileString tds_SQLGetPrivateProfileString
+int tds_SQLGetPrivateProfileString(LPCSTR pszSection, LPCSTR pszEntry,
+                                   LPCSTR pszDefault, LPSTR pRetBuffer,
+                                   int nRetBuffer, LPCSTR pszFileName);


What happens if we use a DLL here? I would assume this test will refer to an undefined symbol and fail to load.

Ah, yeah, (conditional) exporting is in order here. However, I need a static build anyway for the sake of the all_types, connection_string_parse, and utf8_4 tests, so our Windows builds leave this library static-only for simplicity.

Tried to sort out this last hunk. Maybe code for that specific function could be just duplicated somehow? I tried to build for Windows and SQLGetPrivateProfileString from odbc system libraries was used, not the version from shared library.

freddy77 reviewed Jun 1, 2024

View reviewed changes