Its detection wants MINGW64's gcc on x86_64, which went missing when
MSYS2 moved to UCRT64 for QEMU. A cached frida-core hid this until
the 17.19.0 bump.
Nothing packages libfdt, which the arm targets cannot be built
without, so QEMU falls back to the dtc of its own -- and fetching that
wants a git the shell was never given.
MSYS2's profile exports a PKG_CONFIG_PATH of its own, which is read
before PKG_CONFIG_LIBDIR, so zlib, bzip2 and zstd came from the
compiler's own prefix while glib and pixman came from vcpkg. A second
zlib then travelled beside the emulators under the same name as the
app's, and won by sitting closer.
Let go of that path, and point the linker at vcpkg for bzip2, which
asks the compiler rather than pkg-config. Bring zstd along so nothing
is given up for it, say outright that both are wanted so a build
stops rather than quietly dropping them, and leave behind only what
vcpkg has no answer for.
The emulators were downloaded from a qemu-<build> release built in
MSYS2 against MinGW's GLib and pixman, so the installer carried
those beside the vcpkg ones the app links: two copies of GLib and
friends.
Build them in the Windows job instead, against the vcpkg prefix,
cached like the other dependencies on the QEMU version and the
build script. QEMU builds under MinGW and nowhere else on Windows,
but UCRT64 and CLANGARM64 sit on the same C runtime as the MSVC
DLLs they now link, so a descriptor means the same on both sides.
The x86_64 environment moves from MINGW64 for that reason.
The emulators live a directory below the app, where nothing looks
for its GLib on its own, so they are started with the installation
root on PATH.
Windows drops out of the QEMU workflow, which macOS still uses.
Off Apple the xz container was unpacked by running /usr/bin/env xz,
which Windows has no answer for: Process reports that the file does
not exist, and the message reaches the user as it stands.
Decode in-process instead, the way Compression already does on
Apple, and ask for the library the platforms package.
Nothing in the list needs it, but it arrives as a weak dependency, and
Iceberg then loads it into the Pharo VM: the system one brings OpenSSL
3 where the VM already has 1.1, and the handshake to GitHub corrupts
the heap.
frida-core wants Go 1.26 for its compiler backend and Node for the
barebone runtime, and frida-swift now reaches for the GIO headers.
Swift needs ncurses in the snap.
Extract with shortcuts, since the tarball's dangling symlinks defeat
MSYS2's habit of copying what one points at, and install base-devel
for the make and diff that meson and the build itself want.
Build the arm64 flavour on an arm64 runner under CLANGARM64, name the
archive after the arch -- the MSYS2 runtime is x86_64 whatever it
builds for -- and stage it into that installer too.
Unpack the published archive beside the LumaCore bundle, where the
app already looks, and sign every emulator for the hardened runtime;
TCG needs the JIT entitlements.
Name the build once now that more than Windows uses it, and keep a
checksum per platform.
frida-swift to 141d200c, which carries FridaCore 17.18.0. frida-core
to 0602e5dc and radare2 to 84e28a44 for the Windows and Linux builds.
GRDB 7.11.1, swift-asn1 1.7.2, Sparkle 2.9.6.
Drop the Monaco webview. Edit in a GtkSourceView on GTK and in a
native text view on Apple, both speaking to Frida.Compiler's
in-process language server for completions, signature help,
hovers and diagnostics.
Color, complete and indent code natively, matching the GitHub
theme in light and dark.
Same slim build as the Windows one, published to the same qemu-<build>
release as qemu-<build>-macos-arm64.zip -- arm64 only, which is what
the runners are. The binaries link Homebrew dylibs, so the closure is
copied into lib/, every load command rewritten to
@executable_path-relative names, and the touched Mach-Os re-signed
ad hoc. iOS is left out: nothing spawns subprocesses there.
The upstream Windows build carries the GTK, SDL, VNC and curses
frontends, none of which the app drives, and with them a second copy
of GTK in the installer. Build the four emulators and qemu-img from
the unmodified source in MSYS2 with those frontends disabled, keeping
the dbus display, QMP and the gdb stub, and publish the archive
against a qemu-<build> tag the way the shader toolchain is published.
The release notes carry the checksum and name the corresponding
source, which is what GPLv2 asks of a distributor.
Bootstrap provisions Frida, radare2 and the Pharo VM at their pinned
revisions and skips what is present, so a re-run resumes. The Windows
CI job drives it a component at a time. Build from a plain shell via
vcvars, and order the prefixes so a stale Frida cannot win the load.
The app links GtkSourceView for the Pharo editors and librsvg for the
symbolic icons, and neither package said so: on a machine without the
development packages installed, both fail at the first line the loader
reads. The AppImage found this the hard way, having nothing installed
at all.
Repack the Ubuntu 26.04 .deb through sharun, which maps the interpreter
itself and jumps to a stack of its own making. The auxiliary vector it
builds says the program has no interpreter at all, and gum reads that
vector to find the program and the modules beside it, so a library
preloaded ahead of it puts the vector back.
Based on the scripts pkgforge-dev publishes as TEMPLATE-AppImage.
Xcode enumerates a package target's sources when it loads the package
graph, before any build phase or scheme pre-action runs, so generated
Swift that appears during a build is missing from that build.
Move generation into scripts/generate-sources.sh, run it from the
Makefile, CI and the Luma scheme's pre-action, and drop the
AgentBundle target. Say what to run when the files are not there yet.
It came from the CMake build, which downloaded one. The Meson build
links whatever the distro provides, so the prefix holds the VM and
its plugins and nothing else.
No distribution packages a Pharo VM, so what a package leaves out is
what the app goes without: the .rpm and the .deb both installed a
binary whose libPharoVMCore.so nothing on the system provides, and
the flatpak, the snap and the MSI were each short of it in their own
way.
The VM's prefix now ships whole in each of them -- plugins included,
since the image asks for a plugin by name and the VM answers by
looking beside libPharoVMCore, so half a directory is no better than
none.
Nothing on that path ever built one, so the bridge compiled against a
header no pkg-config could point at. Building it there took a VM that
speaks MSVC rather than pthreads, a generation VM for ARM64, and a
prefix named in every dialect of path the toolchain reads -- one
pinned bridge at the end of it, rather than the dozen the search took.
Point frida-swift at the devkit this build made, the way every other
platform does, and drop the xcframework that stood between them.
Leave V8 out of it, sign the dylibs inside the frameworks before the
frameworks themselves, and add the GtkSourceView port Windows needs.
No distribution packages one, so SwiftyPharo asks pkg-config and
the Makefile builds a VM into .build when nothing answers. CI keeps
it in a prefix of its own and finds it again at run time.
The Meson-built VM replaces the CMake one, which brings the plugin
and boot fixes with it.
The playground, the notebook cells, the source editor with its
marks, the inspector columns and the canvas are written once for
both Apple platforms, with a file naming what the two frameworks
call differently. The editor is where they really part company.
The engine owns the image and its start-up, so a mission reaches
the whole of Pharo.
The example catalogue is Smalltalk inside Swift string literals,
which no compiler reads: parse each one in the image and report the
syntax errors, the names nothing defines and the selectors nothing
implements. Play every patch offline. Draw the effects and a
lettered scene offscreen and write a PNG of each, since what goes
wrong in drawing is blank frames and mirrored glyphs.
Play a snippet in a canvas for a while and report what the process
holds as it goes, and let go of what the image lets go of.
glslang and SPIRV-Cross build under neither SwiftPM nor Xcode, so
CI makes them into an xcframework and publishes it against a tag.
The manifest names that artifact; a build downloads it and needs
nothing local.
Write each effect body-only against a preamble the host supplies,
and let the build systems generate what each renderer needs -- a
Swift catalog for OpenGL, a Metal fragment function through glslang
and spirv-cross. Effects react to arriving events.
Call scripts/windows/build.ps1 from the workflow instead of a
duplicated inline recipe. The subst drive-letter mapping is
gone -- setup-env.ps1 strips the redundant -L so the link fits
-- and the separate PKG_CONFIG_PATH step folds into
setup-env.ps1. Keep the vcpkg-environment step; the frida-core
and radare2 meson builds run before it and need pkgconf on
PATH.
The Adwaita icon-theme fetch used Invoke-WebRequest with no timeout,
so a stalled download.gnome.org connection wedged Package MSI for
hours (the step normally runs in under a minute). Bound each attempt
to 120s and retry up to five times, in both the front-load step and
package-msi.ps1.
windows-latest rolled to VS18 / MSVC 14.51, whose STL now demands
Clang 20+; Swift 6.2 ships an older Clang, so every C++ compile
tripped a static_assert. Pin the x86_64 leg to windows-2022 until
the toolchain catches up.
Drop the snap's build-base: devel, which snapcraft resolved to the
26.10 dev series it doesn't recognise. With 26.04 LTS shipped,
core26 stands on its own as a stable base.
TestFlight rejects the IPA because it references the private
_bootstrap_look_up symbol, pulled in via frida-gum's substrated
integration in gumcodesegment-darwin.c. Pass
-Dfrida-gum:jailbreak=disabled for the iOS slices so the generic
code-segment stubs are used instead. Bump the devkit and
xcframework cache keys since they do not capture Meson args.
