From c2adb605316b3fd17a749afa99156bcace9a927f Mon Sep 17 00:00:00 2001 From: Richard Purdie Date: Mon, 22 Jun 2020 17:56:14 +0100 Subject: pseudo: Fix attr errors due to incorrect library resolution issues On a tumbleweed system, "install X Y" was showing the error: pseudo: ENOSYS for 'fsetxattr'. which was being caused by dlsym() for that function returning NULL. This appears to be due to it finding an unresolved symbol in libacl for this symbol in libattr. It hasn't been resolved so its NULL. dlerror() returns nothing since this is a valid symbol entry, its just not the one we want. We can add the glibc version string for the symbol we actually want so we get that version rather than the libattr/libacl one. The calls in libattr are just wrappers around the libc version so our attaching to the libc versions should intercept any accesses via these too. [YOCTO #13952] (From OE-Core rev: 60ae9e6d31dcfc06961fedf7622a204162d3f464) Signed-off-by: Richard Purdie (cherry picked from commit 82655cb26ad01de9587ef41eaef155c61c361f67) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie --- .../pseudo/files/xattr_version.patch | 54 ++++++++++++++++++++++ meta/recipes-devtools/pseudo/pseudo_git.bb | 1 + 2 files changed, 55 insertions(+) create mode 100644 meta/recipes-devtools/pseudo/files/xattr_version.patch diff --git a/meta/recipes-devtools/pseudo/files/xattr_version.patch b/meta/recipes-devtools/pseudo/files/xattr_version.patch new file mode 100644 index 0000000000..a8b14bdd69 --- /dev/null +++ b/meta/recipes-devtools/pseudo/files/xattr_version.patch @@ -0,0 +1,54 @@ +On a tumbleweed system, "install X Y" was showing the error: + +pseudo: ENOSYS for 'fsetxattr'. + +which was being caused by dlsym() for that function returning NULL. This +appears to be due to it finding an unresolved symbol in libacl for this +symbol in libattr. It hasn't been resolved so its NULL. dlerror() returns +nothing since this is a valid symbol entry, its just not the one we want. + +We can add the glibc version string for the symbol we actually want so we get +that version rather than the libattr/libacl one. + +To quote libattr: +""" + These dumb wrappers are for backwards compatibility only. + Actual syscall wrappers are long gone to libc. +""" +and they are simply wrappers around the libc version so our attaching +to the libc versions should intercept any accesses via these too. + +RP 2020/06/22 +Signed-off-by: Richard Purdie