Fix library driver library resolution in musl-based containers#1530
Fix library driver library resolution in musl-based containers#1530elezar merged 2 commits intoNVIDIA:mainfrom
Conversation
Pull Request Test Coverage Report for Build 20753013103Details
💛 - Coveralls |
0b9f8cc to
a1f918d
Compare
|
/cherry-pick release-1.18 |
rahulait
left a comment
There was a problem hiding this comment.
LGTM. I'll let folks who have more context to this repo approve the PR.
cdesiniotis
left a comment
There was a problem hiding this comment.
Thanks @elezar. I have one minor suggestion about logging. I am approving this PR assuming that comment gets addressed. My other two comments are questions that should not be viewed as blockers.
internal/ldconfig/ldconfig.go
Outdated
| return outputListToFile(pathFile, dirs...) | ||
| } | ||
|
|
||
| func isAlpine() bool { |
There was a problem hiding this comment.
Potentially out-of-scope -- is there an easy way of detecting if musl is the standard C library used in a distro? If yes, would we be open to expanding this change to be distro-agnostic? Meaning we would create the /etc/ld-musl-$ARCH.path file for any container that uses musl?
A quick LLM query suggested the below:
ldd --version 2>&1 | grep -q musl && echo "Using musl" || echo "Using glibc"
There was a problem hiding this comment.
I'd be open to a follow-up to make this more generic. Note, however, that we can't run executables from the container as these should be considered untrusted.
Signed-off-by: Evan Lezar <elezar@nvidia.com>
a1f918d to
20ee641
Compare
Signed-off-by: Evan Lezar <elezar@nvidia.com>
|
🤖 Backport PR created for |
Fixes #1526