#sidecar - does tauri prevent sidecar applications from loading shared libraries?

8 messages · Page 1 of 1 (latest)

lusty copper
#

When executing my sidecar .exe it loads without any of it's DLL's. It works if I execute it directly.

Is tauri somehow preventing it from loading these? is this for security? can it be allowed?

lusty copper
#

I just confirmed this happens when I execute with a regular cmd as well so not just for sidecar

lusty copper
#

so I had been using resources to copy the entire application folder over, I read something on github that made me try putting all the files from the application folder directly under src-tauri and add them individually as resources this worked and now the application loads it's DLL's

#

i assume this is a bug?

distant mist
#

well, not really a "bug" it's just how resources and sidecars work.
Sidecars will always be copied to the exe location and resources will be placed in a reconstructed path. so for example a res/my-resource.txt file will also be placed at res/my-resource.txt

#

so it's more like a missing feature to change the paths

quartz parcel
#

The DLL search order is a fun little maze.
What you're seeing in action is the Standard Search Order for Desktop Applications:
https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications

Dynamic-Link Library Search Order - Win32 apps

Applications can control the location from which a DLL is loaded by specifying a full path or using another mechanism such as a manifest. If these methods are not used, the system searches for the DLL at load time as described in this topic.

sleek wren
#

Have you had luck with this approach? I have seen my shared libraries make there way into the application, in my case MacOS. However, the search path for the runtime side to find them is not working. Suggestions on how I might adjust that? I notice an @rpath in the path the library when running otool on the binary.