wasmerio/wasmer · error

Internal error: failed to resolve exported function {name}:

Error message

Internal error: failed to resolve exported function {name}: {e:?}

What it means

apply_resolved_function found the instance for resolved_from, but querying instance.exports.get_function(name) failed; the module does not actually export a function with that name (or it is exported with a different kind). The panic surfaces the underlying lookup error e. This means the resolution table and the module's real export surface disagree.

Source

Thrown at lib/wasix/src/state/linker/instance_group/table.rs:151

        &self,
        store: &mut impl AsStoreMut,
        name: &str,
        resolved_from: ModuleHandle,
        function_table_index: u32,
    ) -> Result<(), LinkError> {
        trace!(
            ?name,
            ?resolved_from,
            function_table_index,
            "Applying resolved function"
        );

        let instance = &self.try_instance(resolved_from).unwrap_or_else(|| {
            panic!("Internal error: module {resolved_from:?} not loaded by this group")
        });

        let func = instance.exports.get_function(name).unwrap_or_else(|e| {
            panic!("Internal error: failed to resolve exported function {name}: {e:?}")
        });

        self.place_in_function_table_at(store, func.clone(), function_table_index)
            .map_err(LinkError::TableAllocationError)?;

        Ok(())
    }

    pub(super) fn apply_function_table_allocation(
        &mut self,
        store: &mut impl AsStoreMut,
        index: u32,
        size: u32,
    ) -> Result<(), LinkError> {
        trace!(index, "Applying function table allocation");
        let allocated_index = self
            .allocate_function_table(store, size, 0)
            .map_err(LinkError::TableAllocationError)? as u32;

View on GitHub (pinned to 8c4b9ee9d3)

Solutions

1. Rebuild the consuming module and the shared library together so resolved symbol names match actual exports (nm/wasm-objdump the exports)
2. Check that the symbol is exported as a function (not a global) in the provider module
3. Clear stale linker/resolution state and re-run the link after replacing a module build
4. If the export exists with the right kind yet the panic persists, report as a linker bug with the module and symbol name

Example fix

// before: lib rebuilt without the export
//   resolution says libfoo exports 'callback', but new build exports 'cb'
group.apply_resolved_function(store, libfoo_handle, "callback", idx);
// after: keep ABI stable or re-resolve against new names
//   export 'callback' in the rebuilt lib, or update the resolution for 'cb'

fn exports_function(inst: &Instance, name: &str) -> bool {
    inst.exports.get_function(name).is_ok()
}
// before apply_resolved_function:
assert!(exports_function(&group.try_instance(handle).unwrap(), "callback"));

fn is_exported_function(inst: &Instance, name: &str) -> bool {
    inst.exports.get_function(name).is_ok()
}

When it happens

Trigger: apply_requested_symbols_from_linker / apply_dl_operation resolving symbol {name} to module X, then X's exports contain no function named {name}; export kind mismatch (name exported as a global/memory instead of a function).

Common situations: Version skew: a shared library was rebuilt and dropped/renamed an exported symbol; symbol name mangling or version-script changes; resolution state built against a different build of the module than the one instantiated.

Related errors

• Internal error: unexpected symbol resolution {r:?} for reque
• Internal error: bad in-progress symbol resolution
• Internal error: missing symbol resolution record for '{0}'.{
• Internal error: failed to resolve function {}: {e:?}
• Internal error: resolution record for symbol {name} indicate

AI-assisted analysis of wasmerio/wasmer@8c4b9ee9d3 (2026-09-01). Data as JSON: /api/errors/b1b53bd50af0a87e. Report an issue: GitHub.