Description
This is really an issue with exthereum/libsecp256k1, but issues are disabled there, so I'm filing it here.
It seems that the current Hex package release of libsecp256k1 depended on by this package contains various precompiled object files (.o, .so, .a, .dylib, .la, .lo, etc.).
It seems, as well, that this project is detected by Mix as being a rebar3 project, despite only actually building properly using rebar.
Because of these two factors, when mix compile or mix deps.compile is run in a project that depends on libsecp256k1, libsecp256k1 won't actually be fully recompiled. The actual final NIF build artifact will be built, but it will be linked against the existing library .a file rather than said file being rebuilt.
This goes unnoticed when compiling on macOS, because the build artifacts in the Hex package are of macOS executable format, so the NIF build step will successfully link them.
However, when compiling on Linux, either the linking step will fail, or the linked NIF will fail to load.
Currently, I'm doing this in a Dockerfile I'm using as a workaround:
RUN mix deps.get
# libsecp256k1's Hex package is thoroughly corrupted
RUN ( cd ./deps/libsecp256k1; \
rm ./priv/libsecp256k1_nif.so ./c_src/libsecp256k1_nif.o && \
rebar compile )
RUN mix do compile, clean
Obviously, it'd be better to just publish a new release of the libsecp256k1 Hex package that doesn't contain these build artifacts.
As well, in order to properly build the dependent library (rather than just the build artifact), I believe exth_crypto needs to use manager: :rebar in its dep spec for libsecp256k1, as without this libsecp256k1 is detected as a rebar3 project for some reason, and rebar3 seems to ignore pre_hooks and post_hooks. (Alternately, libsecp256k1 could be upgraded to be a proper rebar3 project.)