fix: complete the static link line in miniocpp.pc - #265
Conversation
miniocpp.pc declared only `Requires: libcrypto libssl pugixml zlib`, so
`pkg-config --static --libs miniocpp` omitted INIReader/inih and brotli,
and libs3rdma on an RDMA build. libminio.a carries undefined INIReader
and Brotli symbols, so a consumer linking from the .pc alone failed with
undefined references, and had to hand-maintain a parallel list instead.
The .pc cannot see target_link_libraries(), so the private dependencies
are now collected in miniocpp-deps.cmake, at the resolution branch that
knows which one was picked, and emitted as Requires.private/Libs.private.
A hardcoded second list would go stale the same way the first one did.
Requires.private is preferred over a bare -l because these archives live
in the dependency's own prefix, so only the module's own .pc supplies the
-L that finds them; the Libs.private fallback is for deps installed into
miniocpp's libdir, which -L${libdir} already covers. Nothing is named
that pkg-config could not resolve at configure time, so `--libs` for
dynamic consumers is byte for byte what it was.
Brotli reaches libminio.a through cpp-httplib rather than being declared
here, so it is emitted only when the resolved httplib actually enables
CPPHTTPLIB_BROTLI_SUPPORT.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughCMake now records private dependencies for static consumers, including RDMA, Brotli, and inih. It formats this metadata and emits optional ChangesPrivate pkg-config dependencies
Estimated code review effort: 3 (Moderate) | ~20 minutes Suggested reviewers: Sequence Diagram(s)sequenceDiagram
participant CMakeDependencies
participant PkgConfig
participant CMakeLists
participant MiniocppPc
CMakeDependencies->>PkgConfig: Probe private dependency modules
PkgConfig-->>CMakeDependencies: Return module availability
CMakeDependencies->>CMakeLists: Record Requires.private and Libs.private
CMakeLists->>MiniocppPc: Substitute private dependency entries
MiniocppPc-->>CMakeLists: Generate configured pkg-config metadata
Merge Risk: ⚪ Minimal · up to Static pkg-config output now includes resolved private dependencies needed to link libminio.a, while dynamic output remains unchanged. The change is ready to merge. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. A rabbit checks each flag, Comment |
Description
miniocpp.pcdeclared onlyRequires: libcrypto libssl pugixml zlib, sopkg-config --static --libs miniocppomitted INIReader/inih and brotli, andlibs3rdmaon an RDMA build.libminio.acarries undefinedINIReader::*andBrotli*symbols, so a consumer linking from the.pcalone fails withundefined references.
The
.pccannot seetarget_link_libraries(), so the private dependencies arenow collected in
miniocpp-deps.cmakeat the resolution branch that knows whichone was picked, and emitted as
Requires.private/Libs.private. A secondhardcoded list would go stale exactly the way the first one did. The WIN32
MINIO_CPP_PC_EXTRA_LIBSblock is the existing precedent for the same problem.Requires.privateis preferred over a bare-lbecause these archives live inthe dependency's own prefix (a vcpkg tree), so only the module's own
.pcsupplies the
-Lthat finds them. TheLibs.privatefallback is for depsinstalled into miniocpp's own libdir, which
-L${libdir}already covers —libs3rdma(alreadyinstall(FILES ...)-ed besidelibminio) and thesource-built
libminiocpp_inih.a.Brotli is not a dependency declared here: it reaches
libminio.athroughcpp-httplib. It is emitted only when the resolved httplib actually enables
CPPHTTPLIB_BROTLI_SUPPORT, so a build against an httplib without it does notget a
Requires.privatenaming a module that is not installed.Motivation
Consumers currently have to hand-maintain a parallel link list. warp keeps one
in
scripts/rdma-cgo-libs.txt; bumping it to minio-cpp 1.0.0 produced threeseparate build failures that a correct
.pcwould have prevented.How to test
Built minio-cpp 1.0.0 + RDMA against the real vcpkg tree (x64-linux), installed
it, and linked warp using only pkg-config-derived flags:
That reproduces warp's hand-maintained list exactly except
-lstdc++, whichpkg-config cannot know — a cgo consumer still appends the C++ runtime.
Mutation check: deleting the two new fields from the installed
.pcandrelinking fails with undefined references (exit 1), so the fields are
load-bearing.
No regression for existing consumers:
pkg-config --libs miniocpp(dynamic) output is byte-identical to before..pcfiles absent, the new.pcfails exactly as the oldone does, with the same message — from the pre-existing public
Requires: libcrypto, beforeRequires.privateis reached.Both arches were checked for the inputs the generation depends on: the amd64 and
arm64 vcpkg trees ship the same
.pcset and both httplib configs reportHTTPLIB_IS_USING_BROTLI TRUE.Types of changes
Checklist
readelf-lminiocpp_inih) is derived from the installrules and
OUTPUT_NAME, but was not exercised in a build hereminiocpp-deps.cmakeis installed and included byminiocpp-config.cmake, sofind_package(miniocpp)consumers now definethe helper macro and run up to four extra
pkg_check_modulesprobes atconfigure time
Summary by CodeRabbit
Bug Fixes
Requires.privateandLibs.privateinformation.Build Improvements