Repository navigation
Tags: Samsung/escargot
Tags
Fix libwalrus.so/.dylib not being colocated/packaged in release builds ESCARGOT_WASM=ON links walrus as a shared library, but nothing set CMAKE_LIBRARY_OUTPUT_DIRECTORY, so CMake's default per-target behavior under add_subdirectory() placed libwalrus.so/.dylib in a nested build subdirectory (out/third_party/walrus/) instead of next to the escargot binary -- breaking the $ORIGIN/@rpath lookup every release binary relies on for its bundled libraries. Set it alongside the existing CMAKE_RUNTIME_OUTPUT_DIRECTORY so it colocates like every other shared dependency. Verified locally: a WASM-enabled build now produces ./libwalrus.so next to ./escargot, resolves via ldd, and runs correctly from an unrelated cwd. Separately on darwin/ios, CMAKE_INSTALL_RPATH was hardcoded to the ELF-only "$ORIGIN" token, which Mach-O doesn't understand (dyld looks it up literally and fails: "tried: '$ORIGIN/libwalrus.dylib'"). This was a latent no-op there since macOS's release ICU packaging never relied on RPATH (it patches in an explicit @executable_path reference via install_name_tool instead), until walrus's plain-CMake @rpath-based dylib reference made it load-bearing for the first time. Use "@loader_path" (the Mach-O equivalent) on darwin/ios. Also update release.yml to explicitly ship libwalrus.so/.dylib/.dll alongside escargot in all three platforms' packaged release artifacts, and extend the macOS codesign/otool-check loops to cover it. Linux's Deploy step also gets a nullglob fix so its ICU shared-lib copy/patchelf/ldd-check loops don't choke on an unmatched literal glob now that ESCARGOT_LIBICU_SUPPORT_VENDORED=ON statically links ICU in (no libicu* files ever get copied there anymore). Signed-off-by: Seonghyun Kim <[email protected]>
Update java Runtime Exception processing in JNI Signed-off-by: Seonghyun Kim <[email protected]>
PreviousNext