Windows stringzillite might be broken

[ashbob999]

Describe the bug

I think after #181, the stringzillite dll may have been broken.
The addition of the static lib changes, might have made the dll dependent on other dlls.

I have not tested this, but I'm quite sure the problem exists and can look into it when I get chance.

Steps to reproduce

Build the stringzillite dll on windows.

Expected behavior

The dll Is completely standalone.

StringZilla version

3.10.5

Operating System

Windows 10

Hardware architecture

x86

Which interface are you using?

C implementation

Contact Details

No response

Are you open to being tagged as a contributor?

• I am open to being mentioned in the project .git history as a contributor

Is there an existing issue for this?

• I have searched the existing issues

Code of Conduct

• I agree to follow this project's Code of Conduct

[ashvardanian]

@ashbob999, I won't be surprised. I've tried dozens of patches until I've passed the CI for existing targets, and those were not guided by some deep understanding - trial and error at its worst. You must be much more experienced with DLL packaging for Windows and help would be appreciated 🤗

[ashbob999]

I wouldn't say I'm that experienced, but I know some things.

For these changes:
https://github.com/ashvardanian/StringZilla/blob/main/CMakeLists.txt#L331-L338

Were these just trial and error to get it to build, or from external build issues?

[ashvardanian]

It was research-driven, but took multiple attempts 😄

[ashbob999]

I could be wrong, but here's my understanding of what has caused this.

• Issue Bug: sz_dispatch_table didn't initialize in rust binding on Windows #178 and pr Fix dispatch table initilization on msvc target #180, removed the _DllMainCRTStartup function. Which led to the linker error:
  LINK : error LNK2001: unresolved external symbol _DllMainCRTStartup
• Because that function must exist for dlls to be built.
• It then got fixed by MSVC Builds & Python Argument Parsing #181, by linking against the crt libs. Which provide the required functions for the dll.
• Which now means the dll depends of the crt dlls now.

Now I do think the solution to #178 was correct, by adding the sz_dispatch_table_init to the .CRT$XCU section. As thus gets called as part of the global static initialisers, from the crt implementation of _DllMainCRTStartup only.

And as for why these functions weren't being called from the rust library, I have a hunch that they were there but either maybe rust inserts a custom _DllMainCRTStartup function, or simply the linker preferred the version in the crt libs instead.
I probably need to read up of how rust creates its library packages, to know for sure why it worked.

crt init docs