fix: preserve musl compatibility in FIPS build (#1008)

## Why

[#997](#997) added the musl
compatibility check to the FIPS `native-jar` execution, but did not port
the corresponding link and post-link handling from the Linux release
profiles. As a result, FIPS artifacts retain glibc loader and runtime
dependencies that make them fail the new check.

## Changes

- link the C++ runtime and unwinder archives statically in
`fips-boringssl-static`
- remove the architecture-specific `ld-linux` `DT_NEEDED` entry from the
final FIPS native library before the musl check
- document that FIPS, x86_64, and aarch64 profiles each duplicate these
compatibility settings

## Verification

- `xmllint --noout boringssl-static/pom.xml`
- `git diff --check`
- downstream Linux FIPS builds completed successfully on x86_64 and
aarch64, including the native musl compatibility check

Local Maven model validation was not run because this machine has no
Java runtime.

Author: pe-bernard

boringssl-static/pom.xml

@@ -313,6 +313,21 @@
                       </then>
                     </if>
 
+                    <!-- Same ld-linux DT_NEEDED removal as the release profiles.
+                         See docs/musl-compatibility.md -->
+                    <if>
+                      <equals arg1="${os.detected.name}" arg2="linux" />
+                      <then>
+                        <exec executable="patchelf" failonerror="true" dir="${nativeLibOnlyDir}/META-INF/native/linux${archBits}/" resolveexecutable="true">
+                          <arg value="--remove-needed" />
+                          <arg value="ld-linux-x86-64.so.2" />
+                          <arg value="--remove-needed" />
+                          <arg value="ld-linux-aarch64.so.1" />
+                          <arg value="libnetty_tcnative.so" />
+                        </exec>
+                      </then>
+                    </if>
+
                     <!-- Assert the invariants the steps above establish, on the final bytes and
                          before the jar is assembled. Bound here rather than to verify because every
                          build, deploy and staging command is "clean package <plugin>:goal" and so
@@ -398,7 +413,7 @@
                     <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${boringsslCheckoutDir}/include</configureArg>
-                    <configureArg>LDFLAGS=-L${boringsslBuildDir} -lssl -lcrypto -ldecrepit -lstdc++</configureArg>
+                    <configureArg>LDFLAGS=-L${boringsslBuildDir} -lssl -lcrypto -ldecrepit -l:libstdc++.a -l:libgcc.a -l:libgcc_eh.a</configureArg>
                   </configureArgs>
                 </configuration>
               </execution>

docs/musl-compatibility.md

@@ -238,13 +238,13 @@ protocol/cipher against a released version. It must be identical.
 | file | role |
 |---|---|
 | `openssl-dynamic/src/main/c/musl_compat.c` | weak fallbacks for the Class B symbols. Applies to **every** profile, since it is a source file. |
-| `boringssl-static/pom.xml`, antrun `native-jar` target | post-link `patchelf --remove-needed ld-linux-*` (Class A). Present in **both** release profiles: `boringssl-static-default` (x86_64) and `linux-aarch64`. |
+| `boringssl-static/pom.xml`, antrun `native-jar` target | post-link `patchelf --remove-needed ld-linux-*` (Class A). Present in the FIPS profile and both release profiles: `fips-boringssl-static`, `boringssl-static-default` (x86_64), and `linux-aarch64`. |
 | `docker/Dockerfile.centos6` | installs `patchelf` from the upstream prebuilt **static** binary — CentOS 6 is EOL with no EPEL, and `objcopy` cannot remove a `DT_NEEDED`. Needs `--no-check-certificate`, same as the OpenSSL download: the CA bundle cannot verify modern GitHub TLS. |
 | `docker/Dockerfile.cross_compile_aarch64` | installs `patchelf` from EPEL 7 (available there, unlike CentOS 6) |
 
-Note the two release profiles duplicate the whole native build, so **a change to one does not
-apply to the other**. `linux-aarch64` cross-compiles from an x86_64 host; patchelf is
-arch-agnostic and edits the aarch64 object correctly from there (verified), whereas the
+Note the FIPS profile and two release profiles duplicate the whole native build, so **a change to
+one does not apply to the others**. `linux-aarch64` cross-compiles from an x86_64 host; patchelf
+is arch-agnostic and edits the aarch64 object correctly from there (verified), whereas the
 `strip` in that profile has to use the cross-prefixed `aarch64-none-linux-gnu-strip`.
 
 ### Rules for `musl_compat.c`
@@ -438,8 +438,9 @@ Other notes:
 - Ant's `<exec>` does not echo silent commands, so absence of `strip`/`patchelf` output in the
   log does **not** mean they did not run. Verify on the artifact instead.
 - Link flags are set per profile and are duplicated: the x86_64 default profile sets
-  `hawtjniLdflags` in the `ldflags-setup` antrun execution, while the `linux-aarch64` profile
-  hardcodes `LDFLAGS` in its hawtjni `configureArgs`. Changing one does not change the other.
+  `hawtjniLdflags` in the `ldflags-setup` antrun execution, while the FIPS and `linux-aarch64`
+  profiles hardcode `LDFLAGS` in their hawtjni `configureArgs`. Changing one does not change the
+  others.
 
 ---