Open chgeuer opened 7 months ago
@chgeuer thank you for the details!
I don't know yet what is going on, but I would like to know if you are publishing the package from a Windows machine. If so, it is probably a bug related to that. Thanks!
I indeed did the hex publish on a Windows machine.
Sorry for the delay here! I found the problem, and it's very specific to your lib: we check for the string "windows" to determine if the extension is a DLL or a ".so". Since the lib is named "ex_windows_api", we always say it's a DLL.
I honestly don't know how to circumvent that problem :/
I created an Elixir library (
[:ex_windows_api_dataprotection](https://hex.pm/packages/ex_windows_api_dataprotection)
), which calls into a Windows-specific API using Rustler. I use{:rustler_precompiled, "~> 0.7"}
so that my users don't have to have Rust installed. Given that the API is a Windows-specific API, but the package might be installed by non-Windows users, the Rustler function returns the:only_available_on_windows
. I took the:explorer
.github/workflows files as a starting point to userustler_precompiled
.When GitHub actions runs the release build, it creates perfectly fine Windows bits (ex_windows_api_dataprotection-v0.1.2-nif-2.15-x86_64-pc-windows-msvc.dll.tar.gz). When creating the Linux bits, it also correctly creates a libex_windows_api_dataprotection-v0.1.2-nif-2.15-x86_64-unknown-linux-gnu.so.tar.gz file (notice the
.so.tar.gz
in the filename).However, when I run a simple script on a fresh Linux box:
Please note when you now run the same script, it'll work, because I did the workaround described below.
It tried to fetch the Linux bits from a
.dll.tar.gz
file (instead of.so.tar.gz
):I'm trying to understand why the
mix deps.get
orMix.install/1
on Linux tries to fetch a.dll.tar.gz
from the release share, instead of.so.tar.gz
.Workaround: I downloaded the existing
.so...
release, renamed to.dll...
and manually added it to the release, which circumvents the problem for that specific release.After the workaround of manually adding the
dll
file to the release, you can see it being picked up by the sample script: