shankar0123 759e6273e4 fix(deploy/test/libest): CFLAGS=-fcommon + LDFLAGS=--allow-multiple-definition ...

CI run 25193735664 (image-and-supply-chain) showed bullseye-slim
fixed the OpenSSL 3.0 FIPS_mode errors, but the multiple-definition
errors persisted. Root cause was misdiagnosed in commit b253fab —
the cutover isn't binutils 2.35→2.40, it's GCC's -fcommon → -fno-common
default which flipped in GCC 10 (released 2020-05).

bullseye ships GCC 10.2 — already enforces -fno-common. So switching
the base bookworm (GCC 12) → bullseye (GCC 10.2) didn't restore the
default libest 3.2.0 was authored under. The next-older default-
fcommon GCC is 9.x in debian:buster (Debian 10), which went LTS-EOL
June 2024.

Restore the build contract via flags instead of base downgrade:

  CFLAGS=-fcommon
    Restores pre-GCC-10 default for tentative definitions.
    Resolves the 9 'e_ctx_ssl_exdata_index multiple definition'
    errors — libest's est_locl.h:593 declares the global without
    'extern', and pre-GCC-10 every TU could share the tentative
    definition. GCC 10+ requires explicit 'extern' for that.

  LDFLAGS=-Wl,--allow-multiple-definition
    Restores the pre-strict ld behavior that tolerates function-
    level duplicates. Resolves the 'ossl_dump_ssl_errors multiple
    definition' between libest's src/est/est_ossl_util.c:310 and
    example/client/util/utils.c:33 — these are real (non-tentative)
    function definitions; -fcommon doesn't apply, but
    --allow-multiple-definition lets ld link with last-defined-wins.

Both flags propagated to BOTH the configure invocation AND the make
recursive invocation (libest's autotools setup re-runs gcc through
both, and the inner make doesn't always inherit env in libtool's
recursion).

Why this is the proper path:
- These are the documented compatibility flags for projects authored
  under the GCC 9 / pre-strict-ld defaults. They don't disable real
  errors — they restore semantics the libest source assumes.
- Plenty of other projects (e.g., nettle, libtirpc 1.x, openldap 2.4)
  use these same flags for the same reason.

Combined with commit b253fab (bullseye base for OpenSSL 1.1.x ABI),
this is the full set of toolchain-restoration flags libest 3.2.0
requires to build on a 2026-era runtime.

Cannot verify the actual docker build in the sandbox (out of disk +
no docker), but each flag has a textbook explanation for the exact
class of error observed in CI.

2026-04-30 23:12:08 +00:00

..

Dockerfile

fix(deploy/test/libest): CFLAGS=-fcommon + LDFLAGS=--allow-multiple-definition

2026-04-30 23:12:08 +00:00