Skip to content

Add direct symbol references back - #764

Merged
filmor merged 13 commits into
masterfrom
direct-symbol-references
Sep 4, 2026
Merged

Add direct symbol references back#764
filmor merged 13 commits into
masterfrom
direct-symbol-references

Conversation

@filmor

@filmor filmor commented Aug 26, 2026

Copy link
Copy Markdown
Member

This undoes parts of #648. We keep dynamic symbol lookup on Windows (because that is just how it works on this platform) and macOS (because this allows our users to skip messing with linker flags).

The rationale is a forked/vendored copy of rustler that I found, where the dev ran into dlopen(NULL) not being implemented at all in Musl static builds. That means we have to have the "static" linking in place if we want to support that platform.

My initial idea of making the .so callable didn't quite work out, and with the new symbol generation setup, we have a relatively easy way to make cargo-rustler (if we ever implement it fully) expose the necessary symbols to the .so at load time.

@filmor
filmor force-pushed the direct-symbol-references branch 6 times, most recently from fa07f82 to cd697f6 Compare September 2, 2026 09:39
@filmor
filmor force-pushed the direct-symbol-references branch from cd697f6 to 207b958 Compare September 3, 2026 10:16
@filmor filmor self-assigned this Sep 3, 2026
@filmor
filmor requested review from a team and a lite review from Copilot September 3, 2026 15:03

This comment was marked as outdated.

We don't actually require it anywhere else (though it works on Linux
just as well). Also changing the `SysIOVec` type to the (transparent)
safe Rust representation `IoSliceMut` allows us to drop the `libc`
dependency on other systems.
@filmor
filmor marked this pull request as ready for review September 4, 2026 13:20
@filmor
filmor requested a lite review from Copilot September 4, 2026 13:20

This comment was marked as outdated.

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔵 Needs a closer look

SysIOVec is currently changed to a Rust std type that is not FFI/ABI-compatible with the NIF C SysIOVec layout, breaking #[repr(C)] structs and NIF functions that use it.

Review details

Suppressed comments (3)

Previously missed (2) — in code that hasn't changed since the last review.

rustler/src/sys/functions.rs:5

  • The comment says DYN_NIF_CALLBACKS is "defined in the generated api.*.rs", but the generated files reference DYN_NIF_CALLBACKS and the actual static mut DYN_NIF_CALLBACKS is defined here in sys/functions.rs. This mismatch makes the safety/initialization story harder to follow.
    rustler/src/sys/nif_filler.rs:10
  • NoopNifFiller is compiled on all targets but is only used on non-macOS builds (since new() is #[cfg(not(target_os = "macos"))]). On macOS this will be unused and can trigger dead_code warnings; consider cfg-gating the type/impl to the same condition as new().

rustler/src/sys/types.rs:352

  • SysIOVec is part of the NIF C ABI (used inside ErlNifIOQueue/ErlNifIOVec and returned from enif_ioq_peek). Replacing it with std::io::IoSliceMut<'static> makes these #[repr(C)] structs no longer FFI-safe because IoSliceMut has no C layout guarantee and does not match the platform iovec/WSABUF layout expected by the VM.
  • Files reviewed: 34/34 changed files
  • Comments generated: 0 new
  • Review effort level: Lite

@filmor
filmor merged commit 3069af8 into master Sep 4, 2026
83 checks passed
@filmor
filmor deleted the direct-symbol-references branch September 4, 2026 14:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants