GH-49538: [C++][FlightRPC][ODBC] Use static linkage in Windows FlightSQL ODBC driver

[amoeba]

Rationale for this change

The FlightSQL ODBC driver was previously using dynamic linkage for the Arrow deps it relies on. This worked but prevented a challenge for code signing because (I think) we'd have to sign each DLL and signing costs money. We can use static linkage with a dynamically linked MSVC runtime so we only have one DLL to sign.

Ref: #49404

What changes are included in this PR?

Updates to CMake and CI for the build to allow static linkage with dynamic MSVC runtime (x64-windows-static-md).

Are these changes tested?

Yes.

Are there any user-facing changes?

No.

• GitHub Issue: [C++][FlightRPC][ODBC] Change Windows ODBC to Static Linkage #49538

[amoeba]

I have this building locally. Before this PR:

Dump of file release\arrow_flight_sql_odbc.dll

File Type: DLL

  Image has the following dependencies:

    arrow_flight_sql.dll
    arrow_flight.dll
    WSOCK32.dll
    WS2_32.dll
    CRYPT32.dll
    GDI32.dll
    arrow_compute.dll
    arrow.dll
    abseil_dll.dll
    boost_locale-vc143-mt-x64-1_90.dll
    KERNEL32.dll
    USER32.dll
    COMDLG32.dll
    MSVCP140.dll
    MSVCP140_CODECVT_IDS.dll
    VCRUNTIME140.dll
    VCRUNTIME140_1.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll
    api-ms-win-crt-convert-l1-1-0.dll
    api-ms-win-crt-filesystem-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll

After:

Dump of file cpp\build\release\arrow_flight_sql_odbc.dll

File Type: DLL

  Image has the following dependencies:

    ADVAPI32.dll
    IPHLPAPI.DLL
    WSOCK32.dll
    GDI32.dll
    WS2_32.dll
    CRYPT32.dll
    KERNEL32.dll
    USER32.dll
    COMDLG32.dll
    bcrypt.dll
    dbghelp.dll

[github-actions]

⚠️ GitHub issue #49538 has been automatically assigned in GitHub to PR creator.

[lidavidm]

CC @alinaliBQ

[alinaliBQ]

@amoeba I see the branch is about a week old, could we rebase on the latest main? I see there are no conflicts, but I am curious to see if the test code changes at odbc_impl in this PR can incidentally help with #49767 (not required for this PR)

I have tested the ODBC MSI installer manually, and can confirm I am able to retrieve data from Power BI using the installer and static linkage ODBC.

[alinaliBQ]

I was able to build and test release ODBC on my Windows machine locally. But I am getting this error on debug:

I have built from scratch and kept getting this error after several tries. I think this error was from a pre-existing issue where static Debug mode on MSVC was not supported.

absl_synchronization.lib(mutex.cc.obj) : error LNK2005: "private: void __cdecl absl::lts_20250814::Mutex::Dtor(void)" (?Dtor
@Mutex@lts_20250814@absl@@AEAAXXZ) already defined in arrow_flight_static.lib(grpc_client.obj) [C:\path\to\arrow\cpp\static-debug-build\src\arrow\flight\sql\arrow-flight-sql-test.vcxproj]
C:\path\to\arrow\cpp\static-debug-build\debug\Debug\arrow-flight-sql-test.exe : 
fatal error LNK1169: one or more multiply defined symbols found [C:\path\to\arrow\cpp\static-debug-build\src\arrow\flight\sql\arrow-flight-sql-test.vcxproj]
  Building Custom Rule C:/path/to/arrow/cpp/src/arrow/flight/CMakeLists.txt
  test_server.cc
absl_synchronization.lib(mutex.cc.obj) : error LNK2005: "private: void __cdecl absl::lts_20250814::Mutex::Dtor(void)" (?Dtor
@Mutex@lts_20250814@absl@@AEAAXXZ) already defined in arrow_flight_static.lib(protocol_grpc_internal.obj) [C:\path\to\arrow\cpp\static-debug-build\src\arrow\flight\flight-test-server.vcxproj]
C:\path\to\arrow\cpp\static-debug-build\debug\Debug\flight-test-server.exe : fatal error
LNK1169: one or more multiply defined symbols found [C:\path\to\arrow\cpp\static-debug-build\src\arrow\flight\flight-test-server.vcxproj]

(and many errors that look similar)

Since #48964 changes absl bundling, maybe rebasing to main will fix this error on debug static builds.

[amoeba]

Thanks for testing @alinaliBQ. I just rebased and I'll try a debug build locally and report back.

[raulcd]

The ODBC Windows tests seems to be segfaulting:

54/61 Test #55: arrow-flight-sql-odbc-test ................***Exception: SegFault  0.80 sec

This is not happening on main so it might be related.

[amoeba]

I can reproduce the crash locally so that's good. It looks like teardown is triggering the normal unload of arrow_flight_sql_odbc.dll but there are three threads still running and pointing into it? The segfault is:

(6534.5140): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
<Unloaded_arrow_flight_sql_odbc.dll>+0x661f80:
00007fff`92851f80 ??              ???

Three threads are still inside the DLL:

0x9360   0x18   <Unloaded_arrow_flight_sql_odbc.dll>+0x661f80 (00007fff`92851f80)       
0x5140   0x2a   <Unloaded_arrow_flight_sql_odbc.dll>+0x661f80 (00007fff`92851f80)       
0x6004   0x2c   <Unloaded_arrow_flight_sql_odbc.dll>+0x661f80 (00007fff`92851f80)       

Thread details

  24  Id: 6534.9360 Suspend: 1 Teb: 00000088`4062c000 Unfrozen
 # RetAddr               : Args to Child                                                           : Call Site
00 00007ff8`4df1c1ab     : 00000088`41fff5e0 00007fff`9285191a 00000088`00000000 00000088`41fff4c0 : ntdll!NtWaitForAlertByThreadId+0x14
01 00007ff8`4b803f18     : 00000000`00000000 00000088`41fff620 00007fff`93f796f8 00000001`230c2b00 : ntdll!RtlSleepConditionVariableCS+0x14b
02 00007fff`92850691     : 00007fff`93f796c0 00007fff`93f796f8 00000088`41fff5e0 ffffffff`ff676980 : KERNELBASE!SleepConditionVariableCS+0x38
03 00007fff`93f796c0     : 00007fff`93f796f8 00000088`41fff5e0 ffffffff`ff676980 7fffffff`ffffffff : <Unloaded_arrow_flight_sql_odbc.dll>+0x660691
04 00007fff`93f796f8     : 00000088`41fff5e0 ffffffff`ff676980 7fffffff`ffffffff 00000000`00000000 : <Unloaded_arrow_flight_sql_odbc.dll>+0x1d896c0
05 00000088`41fff5e0     : ffffffff`ff676980 7fffffff`ffffffff 00000000`00000000 00000000`00000007 : <Unloaded_arrow_flight_sql_odbc.dll>+0x1d896f8
06 ffffffff`ff676980     : 7fffffff`ffffffff 00000000`00000000 00000000`00000007 00000000`01036640 : 0x00000088`41fff5e0
07 7fffffff`ffffffff     : 00000000`00000000 00000000`00000007 00000000`01036640 00000000`6aba7a43 : 0xffffffff`ff676980
08 00000000`00000000     : 00000000`00000007 00000000`01036640 00000000`6aba7a43 00000001`230c2b00 : 0x7fffffff`ffffffff

# 42  Id: 6534.5140 Suspend: 1 Teb: 00000088`4074e000 Unfrozen
 # RetAddr               : Args to Child                                                           : Call Site
00 00007ff8`4ce7e957     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : <Unloaded_arrow_flight_sql_odbc.dll>+0x661f80
01 00007ff8`4df87c1c     : 00000000`00000000 00000000`00000000 000004f0`fffffb30 000004d0`fffffb30 : KERNEL32!BaseThreadInitThunk+0x17
02 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x2c

 44  Id: 6534.6004 Suspend: 1 Teb: 00000088`40750000 Unfrozen
 # RetAddr               : Args to Child                                                           : Call Site
00 00007ff8`4b832cdc     : 00000000`00000098 00000000`00000024 00000000`00000001 00000000`00000000 : ntdll!NtDeviceIoControlFile+0x14
01 00007ff8`4b832596     : 00000000`00000001 00000000`00000002 00000000`00000000 000001aa`a8e102c8 : KERNELBASE!GetConsoleLangId+0xe8
02 00007ff8`4b7e522d     : 00000000`00000002 00000000`00000000 00000000`00000000 00000000`400c0060 : KERNELBASE!_KernelBaseBaseDllInitialize+0xd6
03 00007ff8`4e05dd5a     : 00000000`00000000 00000000`00000030 000001aa`a8e10000 00000000`00000003 : KERNELBASE!KernelBaseDllInitialize+0xd
04 00007ff8`4df1ba53     : 000001aa`a8e10000 00000000`400c0062 00000000`00000024 00000000`00000030 : ntdll!LdrpCallInitRoutineInternal+0x22
05 00007ff8`4df1b7d7     : 000001aa`a8e17f50 00000088`407f8000 00000088`407f8000 00000000`00000000 : ntdll!LdrpCallInitRoutine+0x93
06 00007ff8`4df8b98b     : 00000000`00000000 00000000`00000000 00000088`407f8000 00000000`00000000 : ntdll!LdrpInitializeThread+0x297
07 00007ff8`4df8b83a     : 00000000`00000000 00007ff8`4df00000 00000088`407f8000 00000088`40750000 : ntdll!LdrpInitialize+0xa7
08 00007ff8`4df0854e     : 00000088`433ff8f0 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!LdrpInitializeInternal+0x5a
09 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!LdrInitializeThunk+0xe

[amoeba]

I figured out the issue I was having with the abseil symbols in 746f8c8 so I was able to remove the /FORCE:MULTIPLE hack.

The segfault looks like what we've seen before in issues such as #49651. I'm not sure but it seems reasonable the stack trace above is showing that there are gRPC threads still in flight when the test suite unloads the driver on teardown, causing the crash. It may be possible to make a refactor to make the tests not crash but I had an agent take a look and it came up with just holding a handle to the driver while the test runs and that seems to fix it: 225cad5

@raulcd @lidavidm does that look okay for a workaround? I'd love to get this into 26.0.0 if we could.

[lidavidm]

Seems fine

[raulcd]

Thanks @amoeba, I'll mark it as 26.0.0, @kou this seems reasonable to me, do you want to double check?
CI failures are unrelated.

[kou]

+1

Let's try this in 26.0.0!