Repository navigation
ELF section .note.ABI-tag breaks shared libraries #3023
Description
Activity
This "atomic bomb" workaround helps too:
find /lib /usr/lib /usr/libexec -name '*.so' | xargs strip --remove-section=.note.ABI-tagWill barf out a few errors where libraries are actually linker scripts. No ill effects.
Reacted by Doğancan Yiğit, lcsondes, Mertcan Ekiz, Hung-I Wang, Michal Fapso, Gabriel Ferreira, Shockingly Good and Florian MeinickeJust came across this in a Google search. Not sure if it is relevant or not but just FYI glibc creates an ABI-invalid .note section for that exact section. I have just filed a bug against glibc about that.
https://sourceware.org/bugzilla/show_bug.cgi?id=23072
I don't know exactly what lupdate is, but if it is a strictly conforming gABI ELF processor it will get wrong values from that section. Just in case that helps.Works for me on Linux in a VM. The ELF standard notwithstanding, having the runtime linker not work due to a quirk in WSL is an issue.
Interestingly enough, the newer shared objects added the option to call them directly, having them say more or less "I'm a library". Calling that
.sodirectly works, it's only linking to it that's broken.What, exactly, is causing this? The ELF note in a shared object is only parsed by the glibc dynamic linker during program loading, not the kernel, so it is unclear to me why there would be a difference between Linux and Windows in this context.
Perhaps the auxiliary vector contains some data which tells glibc not to load the shared object with this kind of ABI note?
What, exactly, is causing this? The ELF note in a shared object is only parsed by the glibc dynamic linker during program loading, not the kernel
I've been also curious for my own edification: What, exactly, is special about the
libQt5Core.sobuild process that generates the (let's call it) unusual binary? I understand the bug cited by jkj. I am just not clear on whylibQt5Coretrips it in this scenario. How would one go about creating ahelloworld.solibrary that exhibits the fail? And why doeslibQt5Coregenerate the binary that way? I could do a deep dive but I suspect someone in this thread (or Ben) already takes the reason as obvious.Yes, it would certainly be interesting to see the output of
objdump -s -j .note.ABI-tag /usr/lib/libQt5Core.so.5.10.1. So far, we only know that the object requires kernel version 3.17.If the Windows kernel self-identifies itself as something earlier than kernel version 3.17, then the dynamic linker is completely right to ignore the object.
Reacted by Oleksandr GavenkoIf the Windows kernel self-identifies itself as something earlier than kernel version 3.17
WSL self identifies as
4.4. But I'd be real real surprised if the linker looks. [I have been surprised before though.]therealkenc Actually, the glibc dynamic linker looks at the ABI notes and refuses to load incompatible DSOs. To determine the kernel version, it prefers the version reported in the vDSO, followed by uname, followed by the contents of
/proc/sys/kernel/osrelease. I wonder if the version in the vDSO isn't 4.4.Reacted by therealkenc and Stanislaw HalikI can't remember the Linux distribution that had the binary. It was either Debian sid or Arch testing. Sorry guys. You can list sections for your own binaries though.
I can't remember the Linux distribution that had the binary.
Ah. That was kinda relevant to mention in the the OP (grumble). This is possibly related to #2820, which was on Arch. In that issue
libQt5Core.so.5exists but could not be opened. The discussion there subsequently went downhill to what was almost certainly arename2()blind alley, and was ultimately closed for lack of a repro. Something this issue is in need of as well; and is likely a contributing factor to the chirping crickets.Noah Baxter (@noahbaxter) it's somewhere in
site-packages.therealkenc the issue's reproducible on Debian sid. You can install it into a chroot via
debootstrapinto the default Ubuntu environment, or some other distro on MSFT Store. When debootstrap doesn't work, downloadcdebootstrap-staticand manually unpack the.debarchive. That one works even on Android.No idea what causes it to begin with, binutils, gcc, GNU libc or something else...?
Reproducible on Gentoo with Qt-5.11.1, Glibc-2.27 and gcc-8.1.0
Stanislaw Halik (@sthalik) : Thanks for your "atomic bomb", this one saved my day! 👍
Reacted by Stanislaw Halik- added a commit that references this issue
on Jun 27, 2018 Ah. That was kinda relevant to mention in the the OP (grumble). This is possibly related to #2820, which was on Arch.
I can confirm that stripping the tag resolves the problem with Arch. Afterwards Qt5 works fine.
Reacted by gnaggnoyil, Oak and changephilipThis "atomic bomb" workaround helps too:
find /lib /usr/lib /usr/libexec -name '*.so' | xargs strip --remove-section=.note.ABI-tagWill barf out a few errors where libraries are actually linker scripts. No ill effects.
This would break programs relying on stripped information in the binary files. For example, modified
/usr/lib/ld-2.28.so(linked as/usr/lib/ld-linux-x86-64.so.2) would not work with valgrind on my Arch Linux instance. This would be fixed by reinstalling the corresponding package which provides the unmodified binary files, which would also void the effect ofstripcommand.22 remaining items
My bad, I did not have binutils in WSL. as it was not throwing any error I didn't realize what was wrong.
i got same issue when installing anaconda3, i found the .so file and trying to run xargs command. i think it is not responding. the shell prompt just blinks indefinitely.
- added a commit that references this issue
on Jun 10, 2019 The author of that ArchWSL known issues Wiki page just picked their personal pet peeves (Qt and, utterly at random,
fakeroot)I haven't read this but see fakeroot-tcp on AUR if it's an issue for any of you.
I have reservations toward a Hyper-V basis for WSL2. Ballooning doesn't solve memory pressure issues as it can result in OOM. Hyper-V is also inferior in several aspects (USB redirection, running X11 as server, lack of OSX support) to VMware and can't be installed alongside it.
Reacted by FrankHB, Chris Charabaruk and NicoleFor those trying to build qt on WSL (like me), the workaround is to use configure arguments :
-no-feature-statx -no-feature-getentropy -no-feature-renameat2(I did not try to reduce to the minimum arguments, so maybe only one of those is actually needed)
EDIT: setting only-no-feature-getentropyfixes the failureAs detailed in nextpnr #444 post-close comments, I am seeing this error in a fresh WSL1 Ubuntu 20.04 install:
error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory$ ls /lib/x86_64-linux-gnu/libQt5Core.so.5 -al lrwxrwxrwx 1 root root 20 Apr 9 00:57 /lib/x86_64-linux-gnu/libQt5Core.so.5 -> libQt5Core.so.5.12.8 $ file /lib/x86_64-linux-gnu/libQt5Core.so.5.12.8 /lib/x86_64-linux-gnu/libQt5Core.so.5.12.8: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=e54a6cea97c3942fbcec1973574545fb3ad74015, for GNU/Linux 3.17.0, stripped $ uname -a Linux DESKTOP-AHQNIJN 4.4.0-18362-Microsoft #836-Microsoft Mon May 05 16:04:00 PST 2020 x86_64 x86_64 x86_64 GNU/Linuxedit: version info WSL on
Microsoft Windows [Version 10.0.18362.836]No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 20.04 LTS Release: 20.04 Codename: focal Python 2.7.18rc1 Python 3.8.2 cmake version 3.16.3 CMake suite maintained and supported by Kitware (kitware.com/cmake). clang version 10.0.0-4ubuntu1 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin qtf_default Version: 5.12.8+dfsg-0ubuntu1 libboost-all-dev Version: 1.71.0.0ubuntu2 build-essential Version: 12.8ubuntu1 clang Version: 1:10.0-50~exp1 bison Version: 2:3.5.1+dfsg-1 flex Version: 2.6.4-6.2 libreadline-dev Version: 8.0-4 gawk Version: 1:5.0.1+dfsg-1 tcl-dev Version: 8.6.9+1 libffi-dev Version: 3.3-4 git Version: 1:2.25.1-1ubuntu3 mercurial Version: 5.3.1-1ubuntu1 graphviz Version: 2.42.2-3build2 xdot Version: 1.1-2 pkg-config Version: 0.29.1-0ubuntu4 python python3 Version: 3.8.2-0ubuntu2 libftdi-dev Version: 0.20-4build8 qt5-default Version: 5.12.8+dfsg-0ubuntu1 python3-dev Version: 3.8.2-0ubuntu2 libboost-dev Version: 1.71.0.0ubuntu2 nextpnr-ecp5: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directorybinutils is already the newest version (2.34-6ubuntu1). binutils set to manually installed. The following package was automatically installed and is no longer required: guile-2.0-libsReacted by Project-MagentaI had an error with libQt5Core on WSL and I fixed it by using this workaround: YosysHQ/nextpnr#444 (comment)
I hope WSL can fix this issue.Reacted by Arron Paul, iakov, Mark Mikofski and Dmitriy Prokazin- added a commit that references this issue
on Apr 28, 2021 this also happens for octave install in WSL1 Ubuntu focal (20.04LTS) from store on Windows 10.0.18363.1556:
$ sudo apt install octave $ octave # doesn't work octave: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory $ sudo strip --remove-section=.note.ABI-tag /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 $ octave # works fineReacted by Faraz and Ondrej BaranovičConsidering running GUI linux apps in win11 is supposed to be a feature, you'd think this 4+ year old bug would have been looked at
glibc 2.36 will remove the kernel version check. From the NEWS file:
- The Linux kernel version check has been removed along with the
LD_ASSUME_KERNELenvironment variable. The minimum kernel used to built
glibc is still provided throughNT_GNU_ABI_TAGELF note and also printed
when libc.so is issued directly.
- The Linux kernel version check has been removed along with the
I'm also facing a similar situation, applying the patch
strip --remove-section=.note.ABI-tagat anywhere Qt5Core.so is located didn't help. What else can i do ?microsoft-github-policy-service commented
on Feb 1, 2024 ContributorThis issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.
Thank you!
Reacted by gojimmypi, Ondrej Baranovič, Sami Boukortt, Air, rj and Yiheng WuHi, I found a workaround by leverage ld.so to load ELF so WSL won't need to parse the problematic ELF file.
Here is my shim script: https://github.com/Inndy/dotfiles/blob/73c86b582d5c8404ab7e0f5a6f40ca6a9078f4c1/bin/fix-wsl-v1-elf-shim
Reacted by 五十嵐 亮
Your Windows build number: (Type
verat a Windows Command Prompt)What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)
Executing
lupdatefrom Qt5 tools,LD_DEBUG=all ldd /usr/lib/libQt5Xml.so, etc.Doesn't treat
libQt5Core.so.5as a suitable library, as perWhat's wrong / what should be happening instead:
As long as ELF section called
.note.ABI-tagexists, the library can't be linked to by other shared objects. It can be executed directly by theld-linuxlinker however.The workaround is to
strip --remove-section=.note.ABI-tag /usr/lib/libQt5Core.so.5.10.1.See how the section's presence influences
file(1)output:Finally, without the section:
Strace of the failing command, if applicable[...]
openatof the library,read,lseek,close, barf out error message on the standard error file descriptor andexit_group.Similarly
LD_DEBUG=allshows opening the ELF without further information other than an error message.After removing the tag, the runtime linking process proceeds normally.