@@ -161,34 +161,60 @@ jobs:
             jars: build-centos6-x86_64-jars
             variant: bare
             extra-pkgs: ""
+            drop-elftools: "1"
             build-service: runtime-setup
             run-service: verify
           - setup: alpine-aarch64
             os: ubuntu-24.04-arm
             jars: build-centos7-aarch64-jars
             variant: bare
             extra-pkgs: ""
+            drop-elftools: "1"
+            build-service: runtime-setup
+            run-service: verify
+          # The invariant leg: an Alpine JDK that ships no `libgcc` package of its own, so
+          # `apk del .elftools` really does leave libgcc absent. eclipse-temurin's JDK depends on
+          # libgcc, so the bare legs above cannot prove the artifact loads without it.
+          - setup: alpine-x86_64-nolibgcc
+            os: ubuntu-24.04
+            jars: build-centos6-x86_64-jars
+            variant: nolibgcc
+            extra-pkgs: ""
+            drop-elftools: "1"
+            jdk-image: amazoncorretto:21-alpine
+            build-service: runtime-setup
+            run-service: verify
+          - setup: alpine-aarch64-nolibgcc
+            os: ubuntu-24.04-arm
+            jars: build-centos7-aarch64-jars
+            variant: nolibgcc
+            extra-pkgs: ""
+            drop-elftools: "1"
+            jdk-image: amazoncorretto:21-alpine
             build-service: runtime-setup
             run-service: verify
           - setup: alpine-x86_64-gcompat
             os: ubuntu-24.04
             jars: build-centos6-x86_64-jars
             variant: gcompat
             extra-pkgs: gcompat
+            drop-elftools: "0"
             build-service: runtime-setup
             run-service: verify
           - setup: alpine-aarch64-gcompat
             os: ubuntu-24.04-arm
             jars: build-centos7-aarch64-jars
             variant: gcompat
             extra-pkgs: gcompat
+            drop-elftools: "0"
             build-service: runtime-setup
             run-service: verify
           - setup: glibc-control-x86_64
             os: ubuntu-24.04
             jars: build-centos6-x86_64-jars
             variant: glibc-control
             extra-pkgs: ""
+            drop-elftools: "0"
             build-service: control-runtime-setup
             run-service: control-verify
 
@@ -207,11 +233,14 @@ jobs:
         env:
           MUSL_VARIANT: ${{ matrix.variant }}
           MUSL_EXTRA_PKGS: ${{ matrix.extra-pkgs }}
+          MUSL_JDK_IMAGE: ${{ matrix.jdk-image }}
         run: docker compose -f docker/docker-compose.alpine.yaml build ${{ matrix.build-service }}
 
       - name: Verify the artifact under ${{ matrix.variant }}
         env:
           MUSL_VARIANT: ${{ matrix.variant }}
           MUSL_EXTRA_PKGS: ${{ matrix.extra-pkgs }}
+          MUSL_DROP_ELFTOOLS: ${{ matrix.drop-elftools }}
+          MUSL_JDK_IMAGE: ${{ matrix.jdk-image }}
           MUSL_JARS_DIR: musl-verify-jars
         run: docker compose -f docker/docker-compose.alpine.yaml run --rm ${{ matrix.run-service }}
@@ -8,9 +8,17 @@ on:
   # deliberately lives on the test branch only. Trigger on push to that branch instead.
   push:
     branches: [ musl-compat ]
+    # Anything that changes the produced artifact must be able to trigger a republish, not just the
+    # publishing machinery itself -- a pom or native-source change with the old filter silently did
+    # nothing.
     paths:
       - '.github/workflows/ci-deploy-github-packages.yml'
-      - '.github/scripts/retarget_staging_index.sh'
+      - '.github/scripts/**'
+      - 'scripts/**'
+      - 'pom.xml'
+      - 'boringssl-static/pom.xml'
+      - 'openssl-dynamic/**'
+      - 'docker/**'
 
   # Usable once/if this workflow is also present on the default branch.
   workflow_dispatch:
 
@@ -214,13 +214,36 @@ jobs:
             jars: build-pr-centos6-x86_64-jars
             variant: bare
             extra-pkgs: ""
+            drop-elftools: "1"
             build-service: runtime-setup
             run-service: verify
           - setup: alpine-aarch64
             os: ubuntu-24.04-arm
             jars: build-pr-centos7-aarch64-jars
             variant: bare
             extra-pkgs: ""
+            drop-elftools: "1"
+            build-service: runtime-setup
+            run-service: verify
+          # The invariant leg: an Alpine JDK that ships no `libgcc` package of its own, so
+          # `apk del .elftools` really does leave libgcc absent. eclipse-temurin's JDK depends on
+          # libgcc, so the bare legs above cannot prove the artifact loads without it.
+          - setup: alpine-x86_64-nolibgcc
+            os: ubuntu-24.04
+            jars: build-pr-centos6-x86_64-jars
+            variant: nolibgcc
+            extra-pkgs: ""
+            drop-elftools: "1"
+            jdk-image: amazoncorretto:21-alpine
+            build-service: runtime-setup
+            run-service: verify
+          - setup: alpine-aarch64-nolibgcc
+            os: ubuntu-24.04-arm
+            jars: build-pr-centos7-aarch64-jars
+            variant: nolibgcc
+            extra-pkgs: ""
+            drop-elftools: "1"
+            jdk-image: amazoncorretto:21-alpine
             build-service: runtime-setup
             run-service: verify
           # Control: anything failing on Alpine must pass here, or the check is at fault rather
@@ -230,6 +253,7 @@ jobs:
             jars: build-pr-centos6-x86_64-jars
             variant: glibc-control
             extra-pkgs: ""
+            drop-elftools: "0"
             build-service: control-runtime-setup
             run-service: control-verify
 
@@ -248,11 +272,14 @@ jobs:
         env:
           MUSL_VARIANT: ${{ matrix.variant }}
           MUSL_EXTRA_PKGS: ${{ matrix.extra-pkgs }}
+          MUSL_JDK_IMAGE: ${{ matrix.jdk-image }}
         run: docker compose -f docker/docker-compose.alpine.yaml build ${{ matrix.build-service }}
 
       - name: Verify the artifact under ${{ matrix.variant }}
         env:
           MUSL_VARIANT: ${{ matrix.variant }}
           MUSL_EXTRA_PKGS: ${{ matrix.extra-pkgs }}
+          MUSL_DROP_ELFTOOLS: ${{ matrix.drop-elftools }}
+          MUSL_JDK_IMAGE: ${{ matrix.jdk-image }}
           MUSL_JARS_DIR: musl-verify-jars
         run: docker compose -f docker/docker-compose.alpine.yaml run --rm ${{ matrix.run-service }}
@@ -599,15 +599,26 @@
                     <echo message="Setup flags to use during linking" />
 
                     <!-- If we compile on linux we need to adjust the ldflags to correct link libstdc++ -->
-                    <!-- NOTE: -static-libgcc was tried here to drop the DT_NEEDED on libgcc_s.so.1
-                         (not a musl-reserved name). It is a no-op in this build: the library is linked
-                         with the C driver, so the _Unwind_* symbols pulled in by libstdc++.a stay
-                         undefined and libgcc_s.so.1 remains genuinely required. Alpine satisfies it
-                         with the `libgcc` package, which the JDK images already install. -->
+                    <!-- The libgcc archives must come *after* libstdc++.a: it is what pulls in the
+                         _Unwind_* symbols, and libgcc_eh.a is what defines them. Linking them
+                         statically is what keeps libgcc_s.so.1 out of DT_NEEDED - `gcc_s.` is not a
+                         musl-reserved stem, so on Alpine that entry is a real file lookup and fails
+                         outright on any image without the `libgcc` package (Amazon Corretto and many
+                         vendor JDK images ship none; eclipse-temurin does, which is why this went
+                         unnoticed). scripts/check_musl_compat.sh asserts both halves.
+
+                         NOTE: spell this as `-l:` and never `-static-libgcc`. GNU libtool 2.4.6 links
+                         the shared library via archive_cmds, which expands only $libobjs $deplibs
+                         $compiler_flags; `-l*` is parsed into deplibs, but `-static-lib*` falls into
+                         func_mode_link's catch-all `-* | +*)` branch and reaches only the *program*
+                         link path, so gcc never sees it. That is why -static-libgcc looked like a
+                         no-op here. `-static-libstdc++` was dropped from this line for the same
+                         reason - it was silently discarded, and -l:libstdc++.a is what actually
+                         linked libstdc++ statically. See docs/musl-compatibility.md. -->
                     <if>
                       <equals arg1="${os.detected.name}" arg2="linux" />
                       <then>
-                        <property name="hawtjniLdflags" value="-L${boringsslHome} -lssl -lcrypto -static-libstdc++ -l:libstdc++.a" />
+                        <property name="hawtjniLdflags" value="-L${boringsslHome} -lssl -lcrypto -l:libstdc++.a -l:libgcc.a -l:libgcc_eh.a" />
                       </then>
                       <else>
                         <property name="hawtjniLdflags" value="${ldflags}" />
@@ -1095,7 +1106,17 @@
                     <configureArg>--libdir=${project.build.directory}/native-build/target/lib</configureArg>
                     <configureArg>CFLAGS=-O3 -Werror -fno-omit-frame-pointer -fvisibility=hidden -Wunused -Wno-unused-value</configureArg>
                     <configureArg>CPPFLAGS=-DHAVE_OPENSSL -I${boringsslSourceDir}/include</configureArg>
-                    <configureArg>LDFLAGS=-L${boringsslHome} -lssl -lcrypto -static-libstdc++ -l:libstdc++.a</configureArg>
+                    <!-- Keep in sync with the boringssl-static-default profile: the two Linux
+                         profiles duplicate the whole native build, so a change to one does not apply
+                         to the other. The libgcc archives must follow libstdc++.a, and must be
+                         spelled `-l:` rather than -static-libgcc because libtool drops the latter -
+                         see the comment on hawtjniLdflags in that profile. On aarch64 this also pulls
+                         libgcc's init_have_lse_atomics constructor into the library, whose
+                         __getauxval reference is satisfied by musl_compat.c; check_musl_compat.sh
+                         fails the build if that ever stops being true, because an unresolved symbol
+                         in an ELF constructor SIGSEGVs the JVM inside dlopen rather than raising
+                         UnsatisfiedLinkError. -->
+                    <configureArg>LDFLAGS=-L${boringsslHome} -lssl -lcrypto -l:libstdc++.a -l:libgcc.a -l:libgcc_eh.a</configureArg>
                     <configureArg>--host=aarch64-linux-gnu</configureArg>
                     <configureArg>CC=aarch64-none-linux-gnu-gcc</configureArg>
                   </configureArgs>
 
@@ -5,17 +5,29 @@
 # work on musl. Nothing here runs Maven, so the os.detected.classifier enforcer rules never come
 # into play.
 #
-# The base is deliberately a stock JDK image with no compatibility shim: it carries musl, libgcc
-# and libstdc++ and no gcompat or libc6-compat, so /lib/libc.so.6 does not exist. That is what
-# "bare" below means, and invariant 1 in docs/musl-compatibility.md permits libgcc_s.so.1
-# precisely because Alpine's libgcc package provides it. If a future base image starts shipping
-# gcompat, the bare variant silently stops testing anything -- verify.sh prints the installed
-# compat packages on every run so that shows up in the log.
+# The base is deliberately a stock JDK image with no compatibility shim: no gcompat and no
+# libc6-compat, so /lib/libc.so.6 does not exist. That is what "bare" below means. If a future base
+# image starts shipping gcompat, the bare variant silently stops testing anything -- verify.sh
+# prints the installed compat packages on every run so that shows up in the log.
+#
+# The default base does ship libgcc and libstdc++, and that is NOT representative: Alpine JDK
+# images differ on it (Amazon Corretto and various vendor images carry no `libgcc` package), which
+# is precisely how a libgcc_s.so.1 DT_NEEDED shipped unnoticed for eight releases.
+#
+# Two knobs are needed to test that honestly, because there are two ways libgcc sneaks in:
+#   - MUSL_DROP_ELFTOOLS=1 makes verify.sh uninstall the binutils below, which depend on libgcc;
+#   - jdk_image must name a JDK that does not itself depend on libgcc. eclipse-temurin does, so on
+#     that base `apk del` cannot remove it and the leg proves nothing about this invariant.
+#     amazoncorretto:21-alpine does not, and still provides javac and jar.
+# See docs/musl-compatibility.md §4b.
 ARG jdk_image=eclipse-temurin:21-jdk-alpine
 FROM ${jdk_image}
 
-# binutils for readelf/nm. It provides no libc symbols, so it cannot mask a missing one.
-RUN apk add --no-cache binutils
+# binutils for readelf/nm. It provides no libc symbols, so it cannot mask a missing one -- but it
+# does pull `libgcc` in as a dependency, which would mask exactly the failure this image exists to
+# detect. Installed as a virtual package so verify.sh can remove it, and libgcc with it, once the
+# ELF inspection is done and only the runtime checks remain.
+RUN apk add --no-cache --virtual .elftools binutils
 
 # Set per variant rather than baked in, so each package set is measured independently.
 # Empty is the invariant; "gcompat" exists to make a bare failure diagnostic, because a fix that
 
@@ -15,12 +15,19 @@ services:
       dockerfile: docker/Dockerfile.alpine
       args:
         EXTRA_PKGS: "${MUSL_EXTRA_PKGS:-}"
+        # eclipse-temurin's JDK depends on libgcc, so `apk del` cannot take it away there and that
+        # base can never prove the artifact loads without it. Point this at an Alpine JDK that
+        # carries no libgcc (amazoncorretto:21-alpine) for the leg that tests exactly that.
+        jdk_image: "${MUSL_JDK_IMAGE:-eclipse-temurin:21-jdk-alpine}"
 
   common: &common
     image: netty-tcnative-alpine:${MUSL_VARIANT:-bare}
     depends_on: [runtime-setup]
     environment:
       - MUSL_VARIANT=${MUSL_VARIANT:-bare}
+      # Set to 1 on the bare legs: uninstalls binutils, and libgcc with it, before the runtime
+      # checks. Leave unset for the gcompat legs, whose point is to load with the shim present.
+      - MUSL_DROP_ELFTOOLS=${MUSL_DROP_ELFTOOLS:-0}
     volumes:
       - ..:/code:delegated
     working_dir: /code
 
@@ -128,6 +128,25 @@ else
 fi
 rm -f "$UND" "$AVAIL"
 
+# ------------------------------------------------------- drop the ELF tools (and libgcc with them)
+# Everything above needs binutils; nothing below does. binutils depends on libgcc, so on an image
+# whose JDK does not itself require libgcc, installing it silently satisfies a libgcc_s.so.1
+# DT_NEEDED and the bare leg stops testing what it claims to. Removing it here means the execution
+# checks -- the ones that actually decide the outcome -- run against the package set a stock Alpine
+# JDK image really has. Guarded on apk so the Debian glibc-control image skips this untouched.
+if [ "${MUSL_DROP_ELFTOOLS:-0}" = "1" ] && command -v apk >/dev/null 2>&1; then
+  echo "-- dropping ELF tools so the runtime checks see no libgcc"
+  apk del .elftools >/dev/null 2>&1 || echo "   WARN: could not remove the .elftools virtual package"
+  echo "   compat now: $(apk info 2>/dev/null | grep -Ex 'gcompat|libc6-compat|libgcc|libstdc\+\+' | sort | tr '\n' ' ')"
+  for lib in /usr/lib/libgcc_s.so.1 /usr/lib/libstdc++.so.6; do
+    if [ -e "$lib" ]; then
+      echo "   note: $lib is still present (the JDK itself depends on it)"
+    else
+      echo "   ok: $lib is absent"
+    fi
+  done
+fi
+
 # ---------------------------------------------------------------- execute
 echo "-- load and initialize"
 CLASSES="$WORK/classes"