shankar0123 7e0a7deeff fix(deploy/test/libest): drop make-time CFLAGS/LDFLAGS pass-through ...

estclient link was failing with `cannot find -lsafe_lib` despite
libsafe_lib.a building cleanly under safe_c_stub/lib/. Root cause:
libest's configure.ac (lines 193-195) appends the bundled safec
stub's path to user-supplied flags:

    CFLAGS="$CFLAGS -Wall -I$safecdir/include"
    LDFLAGS="$LDFLAGS -L$safecdir/lib"
    LIBS="$LIBS -lsafe_lib"

These get baked into the generated Makefile via @CFLAGS@/@LDFLAGS@/
@LIBS@ substitutions. Per automake's variable-precedence rules, a
command-line `make LDFLAGS=...` overrides the `LDFLAGS = @LDFLAGS@`
line in the Makefile — wiping the `-L/src/safe_c_stub/lib` that
configure put there.

The previous commit (f7ee64b) passed these flags at BOTH configure-
time AND make-time. The make-time pass-through was redundant
(configure already baked the flags in) and actively destructive
(it overrode configure's own additions). Configure-time alone is
correct: configure appends to the user's flags, writes the merged
value once, and every link command picks it up.

Verified against upstream r3.2.0:
- safe_c_stub/lib/Makefile.am produces noinst_LIBRARIES=libsafe_lib.a
- example/client/Makefile.am does NOT mention -lsafe_lib explicitly;
  it relies on the configure-baked LIBS+LDFLAGS to bring it in
- top-level Makefile.am has SUBDIRS=safe_c_stub src ... so the stub
  is built before src/est gets a chance to depend on it

CI fix #7 in the ci-pipeline-cleanup post-merge fix-up sequence. Each
"new bug" the cleaned-up CI surfaces is the same shape: a pre-existing
latent bug that the old per-vendor matrix or missing checks
structurally hid. The Docker build smoke step in the new
image-and-supply-chain job is exposing this libest sidecar's full
dependency chain for the first time.

2026-04-30 23:21:59 +00:00

..

Dockerfile

fix(deploy/test/libest): drop make-time CFLAGS/LDFLAGS pass-through

2026-04-30 23:21:59 +00:00