MacOS 26.2 (Tahoe) arm64; I have problems with both the installation of binary and installation via source.

[kwolcott]

Hi;

I saw ArkScript on the Rosetta Code web site. Looks interesting. Want to have ArkScript installed locally on my MacOS 26.2 (Tahoe) arm64 machine. Both the binary installation attempt and the installation from source had problems. I tried to install via source, ran into problems, I asked Gemini AI for help, lots of progress but still have issues. I tried again with a binary installation but I'm running into other problems. I tried to follow the installation instructions provided, but I think I'm missing something essential in getting the runtime/libraries configured.

First, the binary installation issue:

/opt/ArkScript/bin/arkscript ./hello_world_text.ark

dyld[29453]: Library not loaded: @rpath/libArkReactor.dylib
Referenced from: <30D2EF29-4CF9-356E-9240-D1F5A113DB0A> /opt/ArkScript/bin/arkscript
Reason: tried: '/Users/runner/work/Ark/Ark/build/libArkReactor.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/runner/work/Ark/Ark/build/libArkReactor.dylib' (no such file), '/Users/runner/work/Ark/Ark/build/libArkReactor.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/runner/work/Ark/Ark/build/libArkReactor.dylib' (no such file)
./test_it.bash: line 3: 29453 Abort trap: 6 /opt/ArkScript/bin/arkscript ./hello_world_text.ark

ls -R /opt/ArkScript
bin lib libArkReactor.dylib

/opt/ArkScript/bin:
arkscript

/opt/ArkScript/lib:
bitwise.arkm console.arkm database.arkm hash.arkm http.arkm json.arkm playground.arkm std

/opt/ArkScript/lib/std:
Benchmark.ark Events.ark IO.ark Macros.ark Range.ark Sys.ark
Cli.ark Exceptions.ark Lazy.ark Math.ark String.ark Testing.ark
Dict.ark Functional.ark List.ark Random.ark Switch.ark

file /opt/ArkScript/bin/arkscript
/opt/ArkScript/bin/arkscript: Mach-O 64-bit arm64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|WEAK_DEFINES|BINDS_TO_WEAK|PIE>

Thanks in advance for the help,
Ken Wolcott

[kwolcott]

I've been doing some more reading and re-reading. Apparently, MacOS prior to MacOS 15+ needs something from homebrew. I don't use homebrew, I use MacPorts. I want things to be in /opt ; I don't like messing with the MacOS system like homebrew does. Is this a dealbreaker?

Thanks,
Ken Wolcott

[SuperFola]

Could you also try to move libArkReactor.dylib to /opt/ArkScript/bin, so that it's alongside arkscript?

[kwolcott]

This did not work, same error.

[kwolcott]

As I said earlier, my MacOS is 26.2 (Tahoe) and is arm64. I think that, perhaps, the abrupt change that Apple did bumping the OS from 15 to 26 has probably broken the build infrastructure for ArkScript, and that is, perhaps, why this homebrew download piece has been suggested, as a "Hail Mary". This has caused problems for many of the languages I like very much (Nim, Ada, etc) and the problem(s) that have shown up have either been ignored, or treat superficially or even incorrectly/incompletely. So I'm hoping that you guys will take a careful look and see what is going on. The build+install instructions for this version of MacOS and this architecture are not quite right. I'm looking for your help in obtaining a good, clean, seamless and painless installation process for MacOS 26.2 on the arm64 platform. I really like this language, but I'd rather not have to depend on a Docker instance or x86-64 platform, I'd like to run natively.

Thanks,
Ken Wolcott

[SuperFola]

Hi, thanks for the report.

The first solution would be to link libArkReactor to ArkScript statically, in the cmakelists.txt.

I think that would be the best solution going forward, as ArkScript can't be updated independently of libArkReactor, and vice versa.

A second solution seems to be playing with the run paths when compiling ArkScript, as this link suggests : https://www.codegenes.net/blog/how-to-set-dylib-search-path-osx/

---

For the first solution, it should be just replacing SHARED with STATIC here: https://github.com/ArkScript-lang/Ark/blob/dev/CMakeLists.txt#L78

I don't have an installation of macOS Tahoe, for personal reasons I'm sticking to Sequoia (though that might change).

If you could try building and installing from source with the first solution, that would be greatly appreciated!

[kwolcott]

Before embarking on something with some difficulty, please consider a new data point. On a whim, I decided to try executing arkscript from the build directory. It works wonderfully :-) So, apparently, not using an "official" installation method for moving the arkscript binary and libs to the new directory (/opt/ArkScript) causes them to be "confused"? I used "sudo cp -r " to "install" from the build directory. Perhaps that action caused the problem?

Thanks,
Ken Wolcott

[SuperFola]

About the man pages, I didn't make any as this has been a solo project for a few years now, and the entire docs are available online: https://arkscript-lang.dev/docs/prologue/building/, and are downloadable too: https://github.com/ArkScript-lang/website

I find markdown easier to read than man pages, though I understand it comes down to personal preferences!

[kwolcott]

The ArkScript Rosetta Code solutions that I have tried that require an ArkScript lib are now working after updating the ARKSCRIPT_PATH.

Since you said that specifying arm64 is not necessary to obtain an arm64 result, I'll not experiment with that, I'll just comment it out in my build script for the next time.

[kwolcott]

Thanks for the explanation regarding old-style external documentation (man+info) versus new-style documentation. I do think that the new-style documentation is easy to read and understand, so I think that I'm good on this end.

Thank you for your excellent support!

[kwolcott]

I'm not sure how to summarize what all occurred here so I'm not sure which or all of your replies that I should "mark as answer", but I would like to conclude this interaction positively and clearly as resolved.

[SuperFola]

I've posted a summary of what we went through to fix the issue. Please let me know if it needs updating / clarification.

[SuperFola]

To summarize:

• making libArkReactor STATIC in the CMakeLists.txt will solve dynamic libs resolution problems, if you only need the arkscript executable as a user
  • otherwise, when building libArkReactor as a shared library, it should be in the same folder as arkscript
• docs can be found online https://arkscript-lang.dev/docs/prologue/building/, and are downloadable too: https://github.com/ArkScript-lang/website
• if you install ArkScript in a custom directory, eg with cmake --install build --prefix /opt/ArkScript, it will create a /opt/ArkScript/lib/Ark/std, you need to point ARKSCRIPT_PATH to /opt/ArkScript/lib/Ark (I'm working on something to avoid the redundant /Ark/ here, when using a custom installation path, in fix(cmake): add rpath properties for installation #635) for ArkScript to be able to find the standard library

[kwolcott]

Awesome support and summary!
Thanks,
Ken Wolcott