Godot: Cannot load GDNative DLL from within the PCK file

[creikey]

Godot version:

3.1.1

OS/device including version:

Linux cross compiling to Windows

Issue description:

GDnative libraries cannot be loaded from the .pck file when the pattern *.dll is included in the resources regex on the export tab.

Steps to reproduce:

Minimal reproduction project:

[akien-mga]

Can you share an example project?

As far as I know exporting Windows projects with GDNative was done successfully by various users. CC @BastiaanOlij @karroffel

[bruvzg]

GDnative libraries cannot be loaded from the .pck

This is expected, GDNative libs can't be loaded form .pck on any platform, and unlikely it will be ever supported, most platforms don't allow loading libraries from memory.

Libs have to be exported as separate files (exporter should copy .dlls alongside with executable automatically).

[BastiaanOlij]

@bruvzg I was actually wondering about that, I've only ever had to export gdnative plugins for android as I'm happily working in the editor version :)

I should really export a project on Windows and get some experience with deployment :)

[creikey]

@bruvzg What about some engine code that would take the dll dependencies needed for GDNative, pack then into the .pck file on export, then depending on the platform, export the files into the user:// directory then load those?

[bruvzg]

What about some engine code that would take the dll dependencies needed for GDNative, pack then into the .pck file on export, then depending on the platform, export the files into the user:// directory then load those?

This is probably the only reasonable way to support it.

[bruvzg]

But this method may have some potential problems, user:// directory may lack file access permissions required to load libs and anti-viruses may consider such behaviour suspicious.

[BastiaanOlij]

Actually, that’s still a pretty big security hole in Windows, it does allow
this. I don’t know for how long and i feel we’d be contributing to a larger
issue but..

I suggest, if it doesn’t already work this way, to just make sure the dlls
are placed alongside the exe and godot can load them as such. It’s pretty
normal for any Windows application to be deployed that way.

On Tue, 20 Aug 2019 at 2:04 am, bruvzg [e-mail] wrote:

But this method may have some potential problems, user:// directory may
lack file access permissions required to load libs and anti-viruses may
consider such behaviour suspicious.

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/31426?email_source=notifications&email_token=AAO262MWRKATQ7CGINX2J73QFLACVA5CNFSM4IMNYWI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4TOSVY#issuecomment-522643799,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAO262M3MEI3FHTCBGKV4VLQFLACVANCNFSM4IMNYWIQ
.

>

Kindest regards,

Bastiaan Olij

https://www.facebook.com/bastiaan.olij
https://twitter.com/mux213
https://www.youtube.com/BastiaanOlij
https://www.youtube.com/channel/UCrbLJYzJjDf2p-vJC011lYw
https://github.com/BastiaanOlij

[ndarilek]

How does this work for UWP exports? I'm not very familiar with the format but would eventually like to target it.

[marcosjouron]

I can confirm that GDNative libs neither are included in pck files but in they are copied automatically alongside the executable. My tests were in Linux but also I did it in Windows with same results.

[akien-mga]

I tested with 3.2 RC 1 and the GDNative libraries are properly exported next to the .pck:

$ ls
libsimple.dll  UnnamedProject.exe  UnnamedProject.pck

(Cross-compiled from Linux and tested with Wine, but I think it would behave the same on Windows.)

IMO it's fine as is, but if there's really a need to have the libraries in the .pck instead, maybe we can look into how @neikeq did it for Mono assemblies.

[neikeq]

IMO it's fine as is, but if there's really a need to have the libraries in the .pck instead, maybe we can look into how @neikeq did it for Mono assemblies.

.NET assemblies are not native libraries. I don't think it's possible to load native dlls from memory,
I found this some time ago but I don't know if it's safe: https://github.com/fancycode/MemoryModule

A possible solution could be to write the dlls to a temporary disk location before loading them.

[follower]

While I like single file executables, I suspect it probably makes sense to use existing Windows "packing"/"packaging" tooling to achieve it (which has parallels with e.g. AppImage on the Linux side).

I would like the option to have the .dll files put into a subdirectory because that seems "tidier" to my mind, but it also doesn't seem entirely unusual in the Windows world to have them all dumped in the same directory.