Skip to content

Guard the mock library build against undefined NVML symbols #456

Description

@ArangoGutierrez

Problem

The nvml-mock shared library is built with -buildmode=c-shared, which links without --no-undefined. When a go-nvml bump adds new CGo call sites (as v0.13.3-1 did with nvmlDeviceGetAccountingStats_v2, nvmlDeviceGetBBXTimeData_v1, and nvmlSystemGetCPER_v1), the build still succeeds with those symbols left undefined — and the failure only surfaces at e2e, where nvidia-smi's RTLD_NOW dlopen aborts with the misleading message "couldn't find libnvidia-ml.so".

This class of bug is invisible to go build, go vet, go test, and golangci-lint. On #455 it cost a full e2e matrix round (18 failed jobs) to discover; the fix landed in 922df4d.

Proposal

Fail at build time instead. Either (or both):

  1. After building the library, assert no undefined nvml exports remain:
    test -z "$(nm -D libnvidia-ml.so.* | awk '$1=="U" && $2 ~ /^nvml/')"
  2. Add -Wl,--no-undefined to the mock's CGO_LDFLAGS so the link itself fails. Needs validation that the flag plays well with the cgo runtime's expected undefined symbols — option 1 is the narrow, safe check.

A tiny dlopen(RTLD_NOW) smoke probe in the image-build stage would also catch anything symbol-level checks miss.

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions