Support static and dynamic builds across Makefile, CI, and release workflows

[RchGrav]

Motivation

• Preserve the portability gains of producing a static sigmund by default while also supporting dynamic builds for smaller artifacts and CI use-cases.
• Ensure CI and release pipelines can validate and publish both linkage variants across GNU and musl targets so consumers can choose portability vs size.

Description

• Updated Makefile to add LDFLAGS, STATIC_LDFLAGS, and TEST_LDFLAGS, keep static linking as the default build (make) via STATIC_LDFLAGS=-static, and keep an explicit dynamic target make sigmund-dynamic, with test honoring TEST_LDFLAGS.
• Updated CI (.github/workflows/ci.yml) to build both static and dynamic variants in the compiler matrix and to run sanitizer jobs with dynamic linking (STATIC_LDFLAGS='' TEST_LDFLAGS='') to avoid static-sanitizer toolchain issues.
• Reworked release workflow (.github/workflows/release.yml) to produce both GNU static and GNU dynamic artifacts (matrix entries like *-gnu-static and *-gnu-dynamic) while keeping musl artifacts explicitly *-musl-static, and to pass STATIC_LDFLAGS to the make invocation used by dockcross/native builds.
• Updated README.md Quickstart to document the static-by-default behavior, the make sigmund-dynamic option, and recommended CI/release dual-artifact approach.

Testing

• Ran make clean && make which produced a static binary and readelf -d sigmund reported "There is no dynamic section in this file." (static build confirmed).
• Ran make clean && make sigmund-dynamic and readelf -d sigmund showed a dynamic section including Shared library: [libc.so.6] (dynamic build confirmed).
• Ran make clean && make test (default static test build) and the test suite completed with all tests reporting PASS.
• Ran make clean && make test TEST_LDFLAGS='' (dynamic test build) and the test suite also completed with all tests reporting PASS.

---

Codex Task

Summary by Sourcery

Support both static and dynamic sigmund binaries across local builds, CI, and release workflows while keeping static builds as the default.

Enhancements:

• Extend the Makefile to parameterize linker flags, default to static builds, and add an explicit dynamic build target and configurable test linker flags.
• Update CI workflows to build/test both static and dynamic binaries and to run sanitizer jobs with dynamic linking to avoid static-sanitizer toolchain issues.
• Adjust release workflows to produce separate GNU static/dynamic artifacts, standardize musl targets as static-only, and pass static-link flags through dockcross/zig builds.
• Document the static-by-default behavior, the dynamic build option, and recommended dual-artifact strategy in the README Quickstart section.

CI:

• Modify CI matrix jobs to compile both static and dynamic variants and ensure sanitizer tests run against dynamically linked binaries.

Deployment:

• Revise release matrix and build steps to emit distinct static and dynamic GNU artifacts and explicitly static musl artifacts using appropriate build flags.

Documentation:

• Expand README Quickstart to describe static-by-default builds, the dynamic build target, and suggested CI/release publishing strategy for both artifacts.

[sourcery-ai]

Reviewer's Guide

This PR introduces first-class support for both static and dynamic builds of the sigmund binary by parameterizing linker flags in the Makefile and wiring those options through CI and release workflows, while updating documentation to describe the new behavior and recommended usage in automation.

Sequence diagram for GNU release matrix static vs dynamic builds

sequenceDiagram
  participant GH as github_actions
  participant Job as build-linux-gnu_job
  participant Matrix as matrix_entry
  participant Env as build_env
  participant Make as make_system

  GH->>Job: trigger workflow release
  Job->>Matrix: iterate include entries

  loop for each GNU target
    Matrix->>Env: set make_target and static_ldflags
    alt native build (dockcross_image empty)
      Job->>Env: run make clean
      Job->>Make: invoke make make_target with STATIC_LDFLAGS from static_ldflags
      Make-->>Job: produce sigmund or sigmund dynamic
    else dockcross GNU build
      Job->>Env: prepare dockcross script
      Job->>Make: inside container, run make clean and make make_target with STATIC_LDFLAGS from static_ldflags
      Make-->>Job: produce sigmund or sigmund dynamic
    end
    Job->>Job: package tarball using target name (gnu static or gnu dynamic)
  end

Loading

File-Level Changes

Change	Details	Files
Parameterize linking in the Makefile to support static-by-default and optional dynamic builds, including tests.	Added generic LDFLAGS plus STATIC_LDFLAGS (default -static) and TEST_LDFLAGS variables to control binary and test linkage. Modified the default sigmund target to link with both LDFLAGS and STATIC_LDFLAGS so plain make yields a static binary. Introduced a sigmund-dynamic target that omits STATIC_LDFLAGS while still honoring LDFLAGS, producing a dynamically linked sigmund. Updated the test target to link with LDFLAGS and TEST_LDFLAGS so tests can be run with either static or dynamic linkage.	Makefile
Extend CI to build and test both static and dynamic binaries, and run sanitizer jobs with dynamic linking only.	In the main CI job, added an explicit build of the dynamic binary after the static build using the same strict warning flags. In sanitizer jobs, disabled STATIC_LDFLAGS and TEST_LDFLAGS while building and testing with ASan/UBSan to avoid static-sanitizer toolchain issues. Kept the compiler matrix and overall CI structure intact while adding these linkage variants.	.github/workflows/ci.yml
Adjust release workflow matrices and build steps to emit both GNU static/dynamic artifacts and musl static artifacts, correctly passing STATIC_LDFLAGS into make invocations.	Renamed and expanded the GNU target matrix entries into explicit *-gnu-static and *-gnu-dynamic variants, adding per-entry make_target and static_ldflags parameters. Updated native and dockcross GNU build steps to call make with the configured make_target and STATIC_LDFLAGS, ensuring correct static vs dynamic linkage for each artifact. Renamed musl targets to *-musl-static and simplified the zig-based build to always pass STATIC_LDFLAGS='-static' instead of using a static-then-dynamic fallback. Left packaging steps largely unchanged while ensuring artifacts are named consistently with their static/dynamic nature.	.github/workflows/release.yml
Document the static-by-default build behavior and how to produce and distribute both static and dynamic binaries.	Clarified that make now produces a static standalone binary by default, independent of host glibc. Documented the make sigmund-dynamic target as the way to build a smaller, dynamically linked binary. Added guidance recommending publishing both static and dynamic artifacts in CI/release setups, with rationale for when to prefer each.	README.md

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}