update-libcontainer

Reimports vendored libcontainer sources from newer JDK revisions while preserving Native Image adaptations.

21.7k|1.8k|Updated Jan 14, 2016
One-click install
npx skills add https://github.com/oracle/graal --skill update-libcontainer
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: update-libcontainer
Source: https://github.com/oracle/graal/tree/main/substratevm/src/com.oracle.svm.native.libcontainer/skills/update-libcontainer
Command: npx skills add https://github.com/oracle/graal --skill update-libcontainer

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve?

Updating GraalVM Native Image's vendored libcontainer C/C++ sources to a newer JDK revision is error-prone: local NATIVE_IMAGE adaptations must be replayed onto new upstream code, merge conflicts resolved deliberately, and the whole process kept reviewable. This Skill provides a rigorous, commit-by-commit workflow for performing such reimports without losing local changes or upstream fixes.

Core Features & Use Cases

  • Verified merge baseline: Establishes the true previous full-import JDK revision from Git history instead of trusting @BasedOnJDKFile annotations, and validates it by reimporting and diffing.
  • Three-way adaptation replay: Uses diff3-style merges (git merge-file) to replay Native Image adaptations onto new upstream sources, with conflict markers committed separately from their resolutions for reviewability.
  • Reachability minimization: Excludes newly imported code unreachable from exported svm_container_* entry points using whole-definition #ifndef NATIVE_IMAGE guards, and compares external symbols via combined relocatable objects.
  • Effective source projection: Ships scripts/project_native_image.py to materialize the effective Native Image source tree for focused behavioral review commits.
  • Use Case: When a new JDK release changes libcontainer files, use this Skill to reimport them, replay Native Image guards, resolve conflicts, verify symbol-level dependencies, and produce a reviewable commit stack with a documented review guide.

Quick Start

Ask the AI to update the vendored libcontainer sources to a specific new JDK revision while preserving the existing Native Image adaptations in a reviewable commit stack.

Frequently Asked Questions about update-libcontainer

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I update vendored libcontainer sources to a new JDK revision?

First verify the previous full-import baseline from Git history rather than trusting @BasedOnJDKFile annotations. Then remove the namespace, reimport the new JDK files, replay Native Image adaptations with a three-way merge, resolve conflicts in a separate commit, and validate with mx gate checks.

How do I replay local adaptations onto new upstream sources with Git?

Use git merge-file with diff3 markers, treating the old adapted file as ours, the verified old JDK file as base, and the new JDK file as theirs. Commit the marker-bearing result first, then resolve every conflict in an immediately following commit so reviewers can inspect the merge inputs.

Why should I not trust @BasedOnJDKFile annotations as the import baseline?

Annotations may have been advanced without a full reimport to keep change-detection gates passing while the actual import was deferred. The Skill requires inspecting Git history to find the most recent full-import stack and verifying it by reimporting that revision and diffing against the adapted tree.

How do I check which external symbols a static archive depends on?

Combine all archive members into one relocatable object with ld -r --whole-archive, then run nm -u on the result. Raw nm -u on the archive includes references resolved internally, so the combined object gives the true external dependency list to compare between old and new builds.

When should newly imported code be excluded from Native Image?

Exclude any newly imported declaration, definition, field, constant, or include that has no reachability path from an exported svm_container_* entry point, using #ifndef NATIVE_IMAGE around the complete definition. Never add preprocessor conditionals inside a function body without explicit user approval.

What are the limitations of the project_native_image.py projection script?

The script only supports direct #ifdef NATIVE_IMAGE and #ifndef NATIVE_IMAGE forms with optional #else and nested unrelated conditionals. It rejects #elif on NATIVE_IMAGE conditionals and complex expressions; if a new form appears, extend the script and its tests rather than bypassing the failure.