You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The t64 ABI transition renamed libaio.so.1 to libaio.so.1t64, breaking
libnative_device.so which has a hard DT_NEEDED of libaio.so.1. Previously
we worked around this with system-wide symlinks in every Dockerfile and CI
workflow.
Fix this properly in the loader itself:
- CMakeLists.txt now sets RPATH=$ORIGIN (via INSTALL_RPATH +
BUILD_WITH_INSTALL_RPATH + --disable-new-dtags) so libnative_device.so
searches its own directory for dependencies. This lets a managed-side
compat symlink next to the native library satisfy the linker without
any LD_LIBRARY_PATH contortions from the caller.
- libaio_compat.h (new) pins the libaio entry points to the specific
symbol versions that make libaio's userspace fast paths kick in:
io_setup @LIBAIO_0.4
io_destroy @LIBAIO_0.4
io_getevents@LIBAIO_0.4 (userspace ring fast path)
io_submit @LIBAIO_0.1
Older libaio-dev marked LIBAIO_0.4 as the default version so a plain
link picked these up automatically. On t64 (libaio1t64-dev) the default
is gone and libaio.h has no .symver redirects for x86_64, so a fresh
link produces UNVERSIONED references that at runtime resolve to the
slower LIBAIO_0.1 io_getevents which always syscalls and blocks -
which caused NativeStorageDevice probe/TryComplete paths to hang.
- NativeStorageDevice.ImportResolver now resolves NativeLibraryPath to
an absolute path (fixing a latent bug where the relative path
bypassed .NET's runtimes/ probing) and, on Linux, catches
DllNotFoundException referencing libaio.so.1, locates
libaio.so.1t64 in standard multiarch paths, and drops a compat
symlink next to libnative_device.so. The symlink creation tolerates
the race where multiple processes start simultaneously and another
process has already created a usable symlink. If repair still fails,
the loader throws a descriptive DllNotFoundException explaining the
t64 transition and offering three remediation options.
- VectorManager.Initialize() and ResumePostRecovery() now early-return
when IsEnabled is false. Vector Set preview is off by default; there
is no reason these paths should touch storage when the feature is
disabled.
With the loader + build fixes in place, remove the now-redundant
workarounds:
- Dockerfile and Dockerfile.ubuntu: drop the ln -sf libaio.so.1 line.
(Dockerfile.alpine and Dockerfile.azurelinux ship libaio.so.1 natively.
Dockerfile.chiseled uses a restricted runtime and was not touched.)
- .github/workflows/ci.yml and nightly.yml: drop the ubuntu-latest
libaio pre-step; the managed ImportResolver now handles repair
automatically and the test suite actually exercises the repair path.
- validate_docker_images.py: accept either libaio.so.1 or
libaio.so.1t64, since the former is only materialized lazily (on
first native device init) for glibc images now.
The bundled libnative_device.so has been rebuilt against the above
sources with '-O3 -g -DNDEBUG' (project Release defaults). Verified
via objdump -T that io_* references are correctly versioned.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
0 commit comments