You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Q4: does gxplug build on the distributions readers actually have #4
gxplug is verified building and running against Homebrew GCC 16.2 on arm64 macOS, with two quirks that need documenting: -I/opt/homebrew/include for gmp.h, and -Wl,-undefined,dynamic_lookup because Darwin resolves plugin symbols out of cc1 at dlopen time. The plugin also has to be loaded by absolute path.
It is not verified on Debian gcc-16, on Fedora, or on a from source build, on either amd64 or arm64. If plugin builds are commonly painful then B05 and every Tier 1 experiment that depends on gxplug needs a different story, most likely a prebuilt plugin shipped per distribution, which is both a maintenance burden and a trust problem.
Exit criterion. The matrix tested and published in M0, and green in CI by the end of M2.
Work
Build and run on Homebrew, Debian, Fedora and from source, on amd64 and arm64
Add a configure probe to gxplug/Makefile so the reader never has to learn about -Wl,-undefined,dynamic_lookup
Assert compiler output is byte identical with and without the plugin loaded, on every channel
Answered, and the answer is yes on all four channels.
plugin.yml builds and runs gxplug against Debian sid, Fedora rawhide, Homebrew and a from source GCC 16.2, on amd64 and arm64 for three of the four. Homebrew is arm64 only because GitHub's macOS runners are, and the one thing that differs between the two prefixes is /usr/local against /opt/homebrew, which the Makefile never names: it asks brew --prefix, and test_plug.py asserts that it keeps asking.
Build and run on every channel and arch. Done. debian on amd64, debian on arm64, fedora on amd64, fedora on arm64, homebrew on arm64, source on amd64, source on arm64.
A configure probe so the reader never learns about -Wl,-undefined,dynamic_lookup. Done. The Makefile probes and the what the probes decided step prints what it chose on every run, passing or not, because when a channel breaks it is nearly always the probe that broke and not the plugin.
Byte identical output with and without the plugin. Done, and it is a job step rather than a claim in a README. Each channel compiles once with -fplugin=gxplug.so and once without and requires the assembly to match byte for byte.
The two quirks this issue opened over are both handled without the reader seeing them: gmp.h is found through the probed include path, and Darwin's -Wl,-undefined,dynamic_lookup is added only where the probe says it is needed.
Activity
tamnd commentedon Sep 5, 2026
Answered, and the answer is yes on all four channels.
plugin.ymlbuilds and runsgxplugagainst Debian sid, Fedora rawhide, Homebrew and a from source GCC 16.2, on amd64 and arm64 for three of the four. Homebrew is arm64 only because GitHub's macOS runners are, and the one thing that differs between the two prefixes is/usr/localagainst/opt/homebrew, which the Makefile never names: it asksbrew --prefix, andtest_plug.pyasserts that it keeps asking.All six jobs green on #63.
debian on amd64,debian on arm64,fedora on amd64,fedora on arm64,homebrew on arm64,source on amd64,source on arm64.-Wl,-undefined,dynamic_lookup. Done. The Makefile probes and thewhat the probes decidedstep prints what it chose on every run, passing or not, because when a channel breaks it is nearly always the probe that broke and not the plugin.-fplugin=gxplug.soand once without and requires the assembly to match byte for byte.The two quirks this issue opened over are both handled without the reader seeing them:
gmp.his found through the probed include path, and Darwin's-Wl,-undefined,dynamic_lookupis added only where the probe says it is needed.Closing. The first M2 gate on #21 is met.