Description

riveLock() and riveUnlock() are declared with PLUGIN_API in the public header but defined without the EXPORT macro in the implementation file. This means they lack attribute((visibility("default"))) on non-Windows/non-Emscripten platforms and are not reliably visible via dlsym.

Header (native/include/rive_native/external.hpp , lines 83–84):

PLUGIN_API void riveLock(); PLUGIN_API void riveUnlock(); 

Implementation ( native/src/pls_binding.mm, lines 260–261):

// Missing EXPORT — plain C++ linkage, no visibility attribute void riveLock() { g_mutex.lock(); } void riveUnlock() { g_mutex.unlock(); } 

Compare with other functions in the same file that correctly use EXPORT:

EXPORT void* nativeTexture(MetalTextureRenderer* renderer) { ... } EXPORT bool clear(MetalTextureRenderer* renderer, ...) { ... } EXPORT void destroyRiveRenderer(void* renderer) { ... } 

Impact
External consumers that load rive_native as a shared library (e.g., a separate CocoaPod/framework) cannot resolve these symbols via dlsym(RTLD_DEFAULT, "riveLock") — it returns NULL. This prevents third-party code from acquiring the global mutex before calling renderer functions like nativeTexture(), making it impossible to safely serialize access across threads.

Rive's own plugin ( rive_native_plugin.mm ) is unaffected because it links directly within the same compilation unit.

Suggested Fix

-void riveLock() { g_mutex.lock(); } -void riveUnlock() { g_mutex.unlock(); } +EXPORT void riveLock() { g_mutex.lock(); } +EXPORT void riveUnlock() { g_mutex.unlock(); } 

Environment
Package: rive_native 0.1.2
Platform: macOS (ARM64), likely affects iOS and other non-Windows platforms
File: native/src/pls_binding.mm, lines 260–261