Son aktivite 1781952239

factor_raylib_apple_silicon.md Ham

Factor + Raylib on Apple Silicon

Running

/Applications/factor/factor ./game.factor

macOS Setup

Getting Factor and raylib working together on macOS (Apple Silicon) requires a few extra steps due to an architecture mismatch.

The Problem

The official Factor distribution for macOS is x86_64 only — there is no ARM64 build as of June 2026. On Apple Silicon Macs it runs under Rosetta 2.

Homebrew installs native ARM64 packages, so brew install raylib gives you an ARM64 libraylib.dylib that an x86_64 process cannot load:

dll-valid? f
DLL" /opt/homebrew/lib/libraylib.dylib"   ← ARM64, fails in x86_64 Factor

The Fix

Step 1 — Build an x86_64 raylib from source:

git clone --depth 1 https://github.com/raysan5/raylib.git /tmp/raylib-src
cd /tmp/raylib-src/src
make PLATFORM=PLATFORM_DESKTOP RAYLIB_LIBTYPE=SHARED CC="clang -arch x86_64"

Step 2 — Install it to /usr/local/lib:

sudo mkdir -p /usr/local/lib
sudo cp /tmp/raylib-src/src/libraylib.dylib /usr/local/lib/libraylib.dylib

/usr/local/lib is in Factor's default library search path, so it will be found by find-library.

Step 3 — Override the library registration in your .factor file:

Factor's raylib vocabulary registers the library using the bare filename "libraylib.dylib". On a hardened/notarized binary like Factor, macOS strips DYLD_LIBRARY_PATH at launch, so the OS linker can't resolve bare filenames from non-standard paths. However, Factor's own find-library word does its own filesystem search and finds the dylib correctly.

The workaround is to re-register the library with its full path inside a << ... >> parse-time block at the top of your source file:

USING: alien.libraries alien.libraries.finder kernel raylib ;
IN: your-vocab

<< "raylib" "raylib" find-library cdecl add-library >>

The << ... >> block is required — add-library called outside of one runs after alien function stubs are already resolved and has no effect.

Why find-library Works

Factor's macOS library finder searches these paths in order:

  1. DYLD_LIBRARY_PATH (stripped by hardened runtime — always empty)
  2. @executable_path-relative paths
  3. Default fallback: ~/lib, /usr/local/lib, /lib, /usr/lib

Since our x86_64 libraylib.dylib is in /usr/local/lib, find-library returns the full path and dlopen succeeds:

dll-valid? t
DLL" /usr/local/lib/libraylib.dylib"   ← x86_64, works