Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Windows library doesn't work if VCRUNTIME.DLL is missing on host device #33

Closed
2shady4u opened this issue Feb 7, 2021 · 6 comments
Closed
Assignees
Labels
bug Something isn't working question Further information is requested

Comments

@2shady4u
Copy link
Owner

2shady4u commented Feb 7, 2021

Basically if the host device doesn't have any VC++ redistributables installed, the DLL library will fail to load on Windows devices.
This is due to the fact that the DLL has a dependency on VCRUNTIME.DLL libraries that has to be satisfied.

Two possible options are available to solve this issue:

1. Change the MSVC compilation flag from /MD to /MT

This would results in a DLL that includes the runtime dependencies and thus does not dependent on any VC++ redistributables being installed on the host.
https://docs.microsoft.com/en-us/cpp/build/reference/md-mt-ld-use-run-time-library?view=msvc-160

This would require the godot-cpp-repository to update their SConstruct to give the option to select this compilation flag since both the bindings and the library have to be compiled using the same flag. Or I could simply rewrite the SConstruct to handle compilation of both bindings and godot-sqlite in the same file.

2. Compile the library with MinGW instead of MSVC.

Compilation using the MinGW compiler is possible, but currently results in huge library sizes (~14 MB). Most likely due to the fact that the SConstruct doesn't properly set the correct compilation flags for the release target. This might be fixable by only modifying the SConstruct of this library, but I don't know enough about MinGW to make a correct judgement on this one.

Both options are feasible, but I'll have to do some more experimentation and research to resolve this issue in the best way possible...

@progsource
Copy link

In the meantime it would be nice to have a hint in the readme, so that users of the plugin do not run into "No valid library handle" while trying it out ;)

@Aspire5
Copy link

Aspire5 commented Mar 28, 2021

In the meantime it would be nice to have a hint in the readme, so that users of the plugin do not run into "No valid library handle" while trying it out ;)

Yes, Please. I could have never figured it out by myself without the help of @progsource

@2shady4u
Copy link
Owner Author

2shady4u commented Apr 1, 2021

A section has been added to the README.md that addresses this issue.

@2shady4u 2shady4u added bug Something isn't working question Further information is requested labels Apr 4, 2021
@2shady4u 2shady4u self-assigned this Apr 4, 2021
@2shady4u 2shady4u added this to the v2.4 milestone Apr 14, 2021
@2shady4u 2shady4u pinned this issue Apr 16, 2021
@2shady4u
Copy link
Owner Author

2shady4u commented Jun 18, 2021

a third option would be to cross-compile for windows using a linux host device. This might be the solution in this case.

@2shady4u 2shady4u modified the milestones: v2.5, v2.6 Jul 14, 2021
@2shady4u
Copy link
Owner Author

2shady4u commented Aug 1, 2021

I've added a cross-compilation build for Windows to Github Actions which can be downloaded here.

Why is this build not included in Godot SQLite by default?

Currently the binary is excessively large... (~7 MB) There's probably an additional compilation/linker flag that I'm missing to reduce the file size to something more respectable (probably around 4-5 MB). Once I figure out the offending flag, this cross-compilation build becomes the default and closes this issue as a result.

@2shady4u 2shady4u removed this from the v2.6 milestone Aug 1, 2021
@2shady4u 2shady4u unpinned this issue Jan 16, 2022
@2shady4u 2shady4u pinned this issue Jan 16, 2022
@2shady4u 2shady4u unpinned this issue Mar 19, 2022
@2shady4u
Copy link
Owner Author

I'm closing this issue as the default Windows binary included with this plugin is now the MinGW cross-compiled version by default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants
@progsource @Aspire5 @2shady4u and others