Skip to content

Q4: does gxplug build on the distributions readers actually have #4

Closed

Description

@tamnd

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

Activity

  1. added this to the M0 Foundations milestone on Sep 1, 2026
  2. added
    kind/open-questionA question that must be answered by measurement before work depends on it
    kind/toolinggxray, gxplug, bpc, the widgets and the checkers
    priority/p1Needed for the current milestone but not blocking today
    area/buildThe GCC build matrix, containers, CI and the drift bot
    on Sep 1, 2026
  3. tamnd commented on Sep 5, 2026

    @tamnd
    OwnerAuthor

    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.

    All six jobs green on #63.

    • 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.

    Closing. The first M2 gate on #21 is met.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/buildThe GCC build matrix, containers, CI and the drift botkind/open-questionA question that must be answered by measurement before work depends on itkind/toolinggxray, gxplug, bpc, the widgets and the checkerspriority/p1Needed for the current milestone but not blocking today

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions