fix(libffi): publish libffi.so.8 into the subos view - #676
Merged
Conversation
The 3.4.4 tarball ships both soname lines (libffi.so.7.1.0 and libffi.so.8.1.4) but the publish list names only .so.7. Consumers built against .so.8 — xim:glib 2.80.0 is one, its libgio NEEDs libffi.so.8 — then fail mcpp's runtime closure check even though the payload carries the file: the view is what the closure searches, and the view lacks it.
FarnaHerry
added a commit
to FarnaHerry/mcpp-index
that referenced
this pull request
Aug 23, 2026
…ies not symlinks CI on the previous commit failed cold with 'libffi.so.8 is not in this subos'. Root cause chain: xim:glib's libgio NEEDs libffi.so.8; libffi's publish list names only .so.7 though the tarball ships both; the runtime closure searches the subos VIEW, so the missing publish is fatal even though the store holds the file. openxlings/xim-pkgindex#676 fixes the list upstream, but the descriptor must not hinge on it: * resolve() now tiers view -> xim STORE. The view alone is unreliable at hook time in both directions: a publish list can lag the payload (libffi.so.8), and a package already cached in the store skips the config() run that would publish it, leaving a fresh project view without pcre2/zlib (observed on a wiped .mcpp/). The store is complete from the moment a dep is fetched, which for xpm deps is strictly before this hook runs. XLINGS_HOME provides the second store root. * stage() now COPIES instead of symlinking. The subos view is project-local while the payload is shared across projects: a staged symlink dangled the moment the providing project's .mcpp/ was wiped (observed: 'gio/gio.h file not found' off a shared payload). Copies make the payload self-contained; it is version-immutable and already on the consumer's RPATH, so nothing is lost. * header staging gets the same view->store treatment; os.files/os.dirs are not in the xpm sandbox, so globbing goes through the shell. Verified locally against the CI shape: live pkgindex with the libffi fix REVERTED, all hand-made subos workarounds removed, payload and project store wiped — eui-neo passes cold, the other five members pass against the shared self-contained payload.
Contributor
Author
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
问题
libffi 3.4.4 的 tarball 同时携带两条 soname 线(
libffi.so.7.1.0和libffi.so.8.1.4),但config()的发布清单只写了.so.7:针对
.so.8构建的下游 ——xim:glib2.80.0 就是,它的 libgioNEEDs libffi.so.8—— 在 mcpp 的运行时闭包检查里失败:payload 里明明有
libffi.so.8,但闭包检查搜的是 subos 视图,而视图没发布它。修复
发布清单补上
libffi.so.8(一行,另加注释说明为什么两条 soname 线都要在)。已在本机验证:修复后重装 libffi,视图出现libffi.so.8,glib 链路闭包检查通过。背景
这是在给 mcpp-index 的
compat.eui-neo启用 Linux SNI 托盘(EUI_TRAY_SNI,glib/gio over GDBus)时暴露的,mcpplibs/mcpp-index#245 的 CI 依赖本修复先合入。