Bump libdatadog to 38.0.0

[lloeki]

AI-generated code disclosure: this PR was implemented with substantial AI assistance and manually reviewed and validated.

What does this PR do?

Adapts dd-trace-rb to the libdatadog v38 ForkSafeRuntime API, bumps the dependency and native extension version pins to 38.0.0.1.0, and updates every Ruby appraisal lockfile plus the frozen YARD lockfile to the published packages.

Motivation:

The runtime uptake tracked by APMSP-3219 must land separately from the later v39 payload APIs so each published libdatadog-rb package has a single, explicit consumer step.

Change log entry

No.

Additional Notes:

• This is R2, the v38 runtime uptake dd-trace-rb#6131.
• libdatadog-rb#65 and libdatadog-rb#66 have merged; 37.0.0.1.0 and 38.0.0.1.0 are published for all supported package platforms.
• R0 fork safety dd-trace-rb#6127 and R1 exception safety dd-trace-rb#6128 are independent and can be reviewed and merged in either order.
• L0 panic containment libdatadog#2302 has merged. The remaining L1-L5 payload work in libdatadog#2303, libdatadog#2305, libdatadog#2301, libdatadog#2304, and libdatadog#2300 belongs to a future v39 release and package.
• R3 dd-trace-rb#6143 remains the future v39 payload API base. R4 M1 dd-trace-rb#6130, R5 links dd-trace-rb#6129, and R6 events dd-trace-rb#6134 are parallel branches on R3. R7 M2 dd-trace-rb#6132 is based on R4, followed by R8 M3 dd-trace-rb#6133.

How to test the change?

• bundle install
• bundle exec rake clean compile
• bundle exec rspec spec/datadog/core/libdatadog_extconf_helpers_spec.rb spec/datadog/profiling/collectors/cpu_and_wall_time_worker_spec.rb
• bundle exec rake dependency:checksum_coverage
• bundle exec standardrb datadog.gemspec ext/libdatadog_extconf_helpers.rb spec/datadog/core/libdatadog_extconf_helpers_spec.rb
• bundle exec steep check

The native extensions compile against the published x86_64 v38 package. The extconf helper suite passes with 13 examples and 0 failures; checksum coverage, Standard, and Steep pass. The profiling worker suite is currently blocked in the Nix Ruby 4.0.1 environment by an undefined rb_current_box symbol introduced by current master, before R2-specific assertions run; CI provides the supported Ruby/platform coverage.

[dd-octo-sts]

Thank you for updating Change log entry section 👏

^{Visited at: 2026-07-30 12:12:04 UTC}

[lloeki]

Downstream draft stack:

• Export meta struct through native transport #6130 meta_struct M1
  • Encode meta struct values natively #6132 M2
    • Write structured metadata directly #6133 M3
• Export span links through native transport #6129 span links
• Add native span event export #6134 span events

Independent safety PRs that can merge before the release: #6127 and #6128.

[datadog-datadog-us1-prod]

🎉 All green!

🧪 All tests passed
❄️ No new flaky tests detected

🎯 Code Coverage (details)
• Patch Coverage: 100.00%
• Overall Coverage: 90.03% (+0.01%)

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 4b4ee23 | Docs | Datadog PR Page | Give us feedback!}

[pr-commenter]

Benchmarks

Benchmark execution time: 2026-08-04 11:42:57

Comparing candidate commit 4b4ee23 in PR branch lloeki/native-libdatadog-next-uptake with baseline commit 5d50cc4 in branch master.

📊 Benchmarking dashboard

Found 0 performance improvements and 0 performance regressions! Performance is the same for 48 metrics, 1 unstable metrics.

Explanation

This is an A/B test comparing a candidate commit's performance against that of a baseline commit. Performance changes are noted in the tables below as:

• 🟩 = significantly better candidate vs. baseline
• 🟥 = significantly worse candidate vs. baseline

We compute a confidence interval (CI) over the relative difference of means between metrics from the candidate and baseline commits, considering the baseline as the reference.

If the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD), the change is considered significant.

Feel free to reach out to #apm-benchmarking-platform on Slack if you have any questions.

More details about the CI and significant changes

You can imagine this CI as a range of values that is likely to contain the true difference of means between the candidate and baseline commits.

CIs of the difference of means are often centered around 0%, because often changes are not that big:

---------------------------------(------|---^--------)-------------------------------->
                              -0.6%    0%  0.3%     +1.2%
                                 |          |        |
         lower bound of the CI --'          |        |
sample mean (center of the CI) -------------'        |
         upper bound of the CI ----------------------'

As described above, a change is considered significant if the CI is entirely outside the configured SIGNIFICANT_IMPACT_THRESHOLD (or the deprecated UNCONFIDENCE_THRESHOLD).

For instance, for an execution time metric, this confidence interval indicates a significantly worse performance:

----------------------------------------|---------|---(---------^---------)---------->
                                       0%        1%  1.3%      2.2%      3.1%
                                                  |   |         |         |
       significant impact threshold --------------'   |         |         |
                      lower bound of CI --------------'         |         |
       sample mean (center of the CI) --------------------------'         |
                      upper bound of CI ----------------------------------'

Unstable benchmarks

These benchmarks have a confidence interval too wide to call a change; treat them as noise rather than signal.

scenario:tracing - trace.to_digest - Continue

• unstable throughput [-1282.239op/s; +1692.110op/s] or [-4.368%; +5.764%]