Strip duplicate typedefs from vendored common.h (ship 36.0.0.1.1)#62
Draft
lloeki wants to merge 2 commits into
Draft
Strip duplicate typedefs from vendored common.h (ship 36.0.0.1.1)#62lloeki wants to merge 2 commits into
lloeki wants to merge 2 commits into
Conversation
libdatadog v36's generated common.h declares several profiling typedefs
twice: forward "typedef struct X X;" declarations that coexist with the
full "typedef struct X { ... } X;" body (ddog_prof_EncodedProfile,
ddog_prof_StringId, OpaqueStringId) and opaque pointer typedefs emitted
verbatim twice (ddog_prof_StringId2, ddog_prof_MappingId2,
ddog_prof_FunctionId2).
These are legal under C11 but consumers compiling with
-Werror -Wtypedef-redefinition (e.g. dd-trace-rb CI with
DATADOG_GEM_CI=true) treat them as fatal errors. libdatadog's own
dedup_headers tool only removes child-vs-base header duplicates, not
these intra-common.h ones.
Add BuildFromSource::Headers.dedup_common_headers, a build-time
post-processing step that removes the duplicate typedefs from every
vendored common.h after the headers are placed. It runs in the
from-source build flow (rake libdatadog:build) right after the headers
are copied and their permissions fixed. The step is idempotent and only
removes genuine duplicates, logging how many were stripped.
Ship the common.h duplicate-typedef fix without waiting for a new libdatadog release. The packaged library stays at LIB_VERSION 36.0.0; only GEM_MINOR_VERSION is bumped from 0 to 1, yielding gem version 36.0.0.1.1 per the lib_version.gem_major.gem_minor scheme.
lloeki
force-pushed
the
lloeki/header-dedup-postprocess
branch
from
c5336d1 to
7c5e97c
Compare
lloeki
changed the title
This was referenced Jun 22, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
libdatadog v36's generated
common.h(as shipped in36.0.0.1.0) declares several profiling typedefs twice:ddog_prof_EncodedProfile,ddog_prof_StringId,OpaqueStringId(atypedef struct X X;forward decl coexisting with the fulltypedef struct X { ... } X;).ddog_prof_StringId2,ddog_prof_MappingId2,ddog_prof_FunctionId2.These are legal under C11, but consumers compiling with
-Werror -Wtypedef-redefinition(e.g. dd-trace-rb CI withDATADOG_GEM_CI=true) treat them as fatal-Wtypedef-redefinitionerrors. libdatadog's owndedup_headerstool only strips child-vs-base header duplicates, not these intra-common.hones.This lets us ship a clean
36.0.0.1.1gem without waiting for a new libdatadog release.What
Helpers.dedup_common_headers(inRakefile): a build-time post-processing step that removes the duplicate typedefs from every vendoredcommon.hafter the headers are placed.typedef struct X X;forward decls when the full} X;body is present (either order).typedef ...;lines, keeping the first occurrence.rake extract(download/extract release flow) — the release-gem path.rake libdatadog:build(from-source flow).GEM_MINOR_VERSION0->1(LIB_VERSIONstays36.0.0), yielding gem36.0.0.1.1.Validation
Against the real published header (
libdatadog 36.0.0.1.0,x86_64-linuxandx86_64-linux-musl):cc/clang -std=gnu99 -Werror -Wtypedef-redefinition -fsyntax-onlyon a TU that#includesdatadog/common.h:redefinition of typedef ... is a C11 feature).Each of
ddog_prof_EncodedProfile,ddog_prof_StringId,OpaqueStringId,ddog_prof_StringId2,ddog_prof_MappingId2,ddog_prof_FunctionId2now appears exactly once as a typedef. Re-running the step removes nothing (idempotent).rake specpasses (19 examples, 0 failures).Note
One of three coordinated changes for the libdatadog v36 duplicate-typedef header issue (increasing order of permanence):
-Wno-error=typedef-redefinitionstopgap.36.0.0.1.1, without waiting for a libdatadog release.dedup_headers: makescommon.hclean by construction and obsoletes this post-processing once released.Draft pending review of this post-processing approach vs. the upstream libdatadog header fix (libdatadog#2149).