Skip to content

Attempt to fix finding libedit on macOS #609

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
alexcrichton merged 2 commits into from
Mar 12, 2026
Merged

Attempt to fix finding libedit on macOS #609

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fc8afc3
Attempt to fix finding libedit on macOS
alexcrichton Mar 11, 2026
e3194e3
Another attempted fix
alexcrichton Mar 11, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions cmake/wasi-sdk-toolchain.cmake
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -113,6 +113,9 @@ if(WASI_SDK_LLDB)
include(ProcessorCount)
ProcessorCount(nproc)
find_program(MAKE_EXECUTABLE make REQUIRED)
if(CMAKE_SYSTEM_NAME STREQUAL Darwin)
set(libedit_ldflags -Wl,-install_name,@rpath/libedit.0.dylib)
Copy link

@cfallin cfallin Mar 11, 2026

Choose a reason for hiding this comment

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

Do we set the rpath to ../lib somewhere (or does CMake do that automatically)? Or should this be @rpath/../lib/libedit.0.dylib?

Copy link
Collaborator Author

@alexcrichton alexcrichton Mar 11, 2026

Choose a reason for hiding this comment

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

Eh this doesn't even work as-is given CI (and more local testing), so I'm still flailing trying to figure this out

Copy link
Collaborator Author

@alexcrichton alexcrichton Mar 11, 2026

Choose a reason for hiding this comment

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

My current thinking is: no, but that's only because the -install_name for libLLVM.dylib is @rpath/libLLVM.dylib. My ill-informed rationale is that the executable is responsible for saying what it's rpath is, and then the libraries linked say "ok sure and now you find me in the rpath"

endif()
ExternalProject_Add(libedit
URL https://thrysoee.dk/editline/libedit-20251016-3.1.tar.gz
URL_HASH SHA256=21362b00653bbfc1c71f71a7578da66b5b5203559d43134d2dd7719e313ce041
Expand All @@ -127,8 +130,7 @@ if(WASI_SDK_LLDB)
--enable-pic
--disable-examples
CC=${CMAKE_C_COMPILER}
CFLAGS=${libedit_cflags}
LDFLAGS=${libedit_cflags}
LDFLAGS=${libedit_ldflags}
BUILD_COMMAND
${MAKE_EXECUTABLE} -j${nproc} V=1

Expand Down Expand Up @@ -169,6 +171,9 @@ ExternalProject_Add(llvm-build
# Pass `-s` to strip symbols by default and shrink the size of the
# distribution
-DCMAKE_EXE_LINKER_FLAGS=-s
# Looks to be required on macOS for, at build time, the dynamic linker to
# find `libedit.dylib` when that's enabled.
-DCMAKE_BUILD_RPATH=${wasi_tmp_install}/lib
${llvm_cmake_flags_list}
# See https://www.scivision.dev/cmake-externalproject-list-arguments/ for
# why this is in `CMAKE_CACHE_ARGS` instead of above
Expand Down
Loading