Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ELF section .note.ABI-tag breaks shared libraries #3023

Open
sthalik opened this issue Mar 14, 2018 · 36 comments

Comments

Projects
None yet
@sthalik
Copy link

commented Mar 14, 2018

Your Windows build number: (Type ver at a Windows Command Prompt)

10.0.16299.192
Linux ananke 4.4.0-43-Microsoft #1-Microsoft Wed Dec 31 14:42:53 PST 2014 x86_64 GNU/Linux
Debian sid

What you're doing and what's happening: (Copy&paste specific commands and their output, or include screen shots)

Executing lupdate from Qt5 tools, LD_DEBUG=all ldd /usr/lib/libQt5Xml.so, etc.

Doesn't treat libQt5Core.so.5 as a suitable library, as per

lupdate: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory

What's wrong / what should be happening instead:

As long as ELF section called .note.ABI-tag exists, the library can't be linked to by other shared objects. It can be executed directly by the ld-linux linker 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:

/usr/lib/libQt5Core.so.5.10.1: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=147dcf3333ff6b490dabb4028a217effa08013e3, for GNU/Linux 3.17.0, stripped

Finally, without the section:

/usr/lib/libQt5Core.so.5.10.1: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=147dcf3333ff6b490dabb4028a217effa08013e3, stripped

Strace of the failing command, if applicable[...]

openat of the library, read, lseek, close, barf out error message on the standard error file descriptor and exit_group.

Similarly LD_DEBUG=all shows opening the ELF without further information other than an error message.

      3954:     file=libQt5Core.so.5 [0];  needed by lupdate [0]
      3954:     find library=libQt5Core.so.5 [0]; searching
      3954:      search path=/usr/lib           (system search path)
      3954:       trying file=/usr/lib/libQt5Core.so.5
      3954:      search cache=/etc/ld.so.cache
      3954:      search path=/usr/lib           (system search path)
      3954:       trying file=/usr/lib/libQt5Core.so.5
      3954:
lupdate: error while loading shared libraries: libQt5Core.so.5: cannot open shared object file: No such file or directory

After removing the tag, the runtime linking process proceeds normally.

@sthalik

This comment has been minimized.

Copy link
Author

commented Mar 14, 2018

This "atomic bomb" workaround helps too:

find /lib /usr/lib /usr/libexec -name '*.so' | xargs strip --remove-section=.note.ABI-tag

Will barf out a few errors where libraries are actually linker scripts. No ill effects.

@jkj

This comment has been minimized.

Copy link

commented Apr 17, 2018

Just 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.

@sthalik

This comment has been minimized.

Copy link
Author

commented May 17, 2018

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 .so directly works, it's only linking to it that's broken.

@fweimer

This comment has been minimized.

Copy link

commented May 19, 2018

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?

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented May 19, 2018

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.so build process that generates the (let's call it) unusual binary? I understand the bug cited by jkj. I am just not clear on why libQt5Core trips it in this scenario. How would one go about creating a helloworld.so library that exhibits the fail? And why does libQt5Core generate 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.

@fweimer

This comment has been minimized.

Copy link

commented May 19, 2018

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.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented May 19, 2018

If 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.]

@fweimer

This comment has been minimized.

Copy link

commented May 19, 2018

@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.

@sthalik

This comment has been minimized.

Copy link
Author

commented May 19, 2018

I 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.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented May 19, 2018

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.5 exists but could not be opened. The discussion there subsequently went downhill to what was almost certainly a rename2() 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.

@sthalik

This comment has been minimized.

Copy link
Author

commented May 28, 2018

@noahbaxter it's somewhere in site-packages.

@therealkenc the issue's reproducible on Debian sid. You can install it into a chroot via debootstrap into the default Ubuntu environment, or some other distro on MSFT Store. When debootstrap doesn't work, download cdebootstrap-static and manually unpack the .deb archive. That one works even on Android.

No idea what causes it to begin with, binutils, gcc, GNU libc or something else...?

@Yamakuzure

This comment has been minimized.

Copy link

commented Jun 22, 2018

Reproducible on Gentoo with Qt-5.11.1, Glibc-2.27 and gcc-8.1.0

@sthalik : Thanks for your "atomic bomb", this one saved my day! 👍

kdudka added a commit to kdudka/csmock that referenced this issue Jun 27, 2018

chroot-fixups/qt5-core-abi.sh: make libQt5Core.so.5 load on el7 kernel
... by stripping an incompatible ABI note as suggested here:

microsoft/WSL#3023
@ChrisTX

This comment has been minimized.

Copy link

commented Aug 8, 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.

@FrankHB

This comment has been minimized.

Copy link

commented Sep 27, 2018

This "atomic bomb" workaround helps too:

find /lib /usr/lib /usr/libexec -name '*.so' | xargs strip --remove-section=.note.ABI-tag

Will 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 of strip command.

@du291

This comment has been minimized.

Copy link

commented Dec 7, 2018

Hello, I have a problem that Qt5 based applications won't run on WSL. After googling I was drawn here.
I haven't stripped yet the ABI tag from the lib, and hope to create more insight into the problem.

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.

Here's the dump

$ objdump -s -j .note.ABI-tag /lib/libQt5Core.so.5|less

/lib/libQt5Core.so.5: file format elf64-x86-64

Contents of section .note.ABI-tag:
4ef138 04000000 10000000 01000000 474e5500 ............GNU.
4ef148 00000000 03000000 11000000 00000000 ................

Feel free to ask for more info.

@ChrisTX

This comment has been minimized.

Copy link

commented Jan 8, 2019

For ArchLinux users, it's possible to utilize pacman hooks to automatize the stripping of the libQt5Core.so during the installation or upgrade of Qt. Simply create a .hook file in /etc/pacman.d/hooks with the following contents:

[Trigger]
Operation = Install
Operation = Upgrade
Type = Package
Target = qt5-base

[Action]
Depends = binutils
When = PostTransaction
Exec = /usr/bin/strip --remove-section=.note.ABI-tag /usr/lib/libQt5Core.so

Upon every Qt5 upgrade after that, the offending section will be stripped automatically. If qt5-base was already installed, simply force a reinstallation.

@du291

This comment has been minimized.

Copy link

commented Jan 8, 2019

Thanks for the tip. Does the stripping result in any instability? If the ABI versions don't match I would imagine Qt issuing an unsupported syscall sooner or later?

@ChrisTX

This comment has been minimized.

Copy link

commented Jan 8, 2019

No, the field is to be read as follows, see here and here: The minimum kernel version for the binary is required to be the Linux kernel version given by the last 3 blocks, i.e. in your case 0x03, 0x11, 0x00, so 3.17.0. For latest Arch binaries it's 0x04, 0x0b, 0x00, so 4.11.0. Given that WSL identifies as Linux kernel 4.4.0, the binary is incompatible.

It's worth noting that the ABI tag is specified and required for LSB binaries, and that this is not an issue with Qt5 at all. I can't say why Qt5 uses the field, but LSB requires support for it, and the low kernel version emulated by Microsoft is the issue here. This is by design enforced by the dynamic linker and thus the installed glibc version of the user space, and the respective Linux distro. It would be nice if Microsoft worked towards finding a better version scheme or updated the version identifier at least somewhat regularly in upgrades to WSL.

FWIW, stripping the tag only disables the check by the dynamic linker for the kernel version to be at least as high and has no other effects. So if a given binary works after the check was removed, it won't cause any particular issues or changes in behavior. For WSL the kernel version isn't particularly meaningful anyways.

@ChrisTX

This comment has been minimized.

Copy link

commented Jan 8, 2019

Okay, I've debugged this a bit, there's actually another issue at hand here. Since I've got this on Arch with a requirement of 4.11.0 I thought it was just the fact that the kernel version is too low. However that's not quite the case, and that's why people with the older 3.17.0 version see this too.

This needs a bit of explanation how glibc works, so bear with me. The version check we ultimately run into can be found in the glibc source file /sysdeps/unix/sysv/linux/dl-sysdep.c in the glibc sources. The responsible function there is _dl_discover_osversion. If the output of that function is too low in comparison to what .note.ABI-tag requires, glibc refuses to load the binary at all, see /elf/dl-load.c for the respective code segment.

Now, _dl_discover_osversion tries discovering the kernel version by the following three methods:

  1. Check the loaded kernel vDSO for a .note section that identifies the kernel.
  2. Use uname(2)
  3. Use /proc/sys/kernel/osrelease

The problem for us is going to be 1), the other two identify as kernel 4.4.0. To see what 1 gives, we need to dump the kernel vDSO ourselves. The easy way to do this is by opening gdb on any arbitrary process, using info proc map to see the mapping of [vdso] and then dump it using the dump command. For example, it looked like this for me:

(gdb) info proc map
[…]
      0x7ffffffef000     0x7fffffff0000     0x1000        0x0 [vdso]
(gdb) dump binary memory vdso.dump 0x7ffffffef000 0x7fffffff0000

Now with vdso.dump on disk, we can analyze the section glibc parses, namely:

$ objdump -s -j .note vdso.dump

vdso.dump:     file format elf64-x86-64

Contents of section .note:
 ffffffffff700318 06000000 04000000 00000000 4c696e75  ............Linu
 ffffffffff700328 78000000 0b0d0300                    x.......

The relevant part is the last 4 bytes, it is to be read as kernel version 0x03.0x0d.0x0b, i.e. kernel 3.14.11. This is not correct however, since WSL wants to identify as kernel 4.4.0, and this has to match uname(2). This precisely is why people have been seeing the error with requirements of kernel 3.17.0.

@therealkenc can you forward this to whoever is responsible for the vDSO?

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented Jan 8, 2019

Very nice investigation. 🏆

@therealkenc can you forward this to whoever is responsible for the vDSO?

I don't really know whose around anymore. @benhillis maybe.

What might help the chances of this one being looked at immeasurably would be specific repro steps to create a shared library with one int hello() function that results in the error while loading shared libraries when the library is linked with a one-liner main() that calls return hello().
Doing that has the nice properties of: (a) avoids saying 'libQt' which is technically out of scope (b) avoids saying 'Arch', which isn't in the Store. Which is at base why/how this one went dark.

Same was suggested in May 2018. It might be overkill, your analysis might be self-evident, and this might be a matter of changing a {0x03,0x0d,0x0b} constant in the vDSO. But that's a lot of mights, and a new well-formed issue is how I'd try to get attention.

@ChrisTX

This comment has been minimized.

Copy link

commented Jan 8, 2019

Right, I'll see if I can generate a simple example. It's easily reproduced by using a similar trick to what Qt5 itself does. They explicitly add an assembly file with the section information and have a header that differentiates between the available kernel features it was configured with. Qt5 can use renameat(2), getentropy(2) and statx(2), which were introduced in 3.16, 3.17, and 4.11 accordingly. It should be noted that WSL (as of 1809 at least) supports all three syscalls despite identifying as 4.4. I suspect the original reason people blamed renameat(2) is related to this, too - if you configured Qt5 with it, it requires kernel 3.16, but to glibc it appears as if 3.14.11 was in use, making the binary invalid.

Aside from the mismatch, which can be easily reproduced and argued why it's an issue - LSB also demands that LSB compliant binaries require the proper kernel version, and if renameat(2) is used, it should be 3.16 - the second problem at hand here is that the kernel version of 4.4 is too low. It makes little sense to retain an older kernel identifier other than for kernel modules, which WSL obviously does not have.

That aside, I don't understand why Qt5 would be entirely out of scope. Qt is not a GUI library in itself, and there's a lot of features in the library that have nothing to do with GUI or hardware abstractions, like XML parsers, an SQL abstraction layer, networking, concurrency extensions, and these are also common place in the C++ world, even on servers. The problem also has nothing to do with the combination of Qt and certain distros, but rather depends on what syscalls are exposed in the glibc of the system the binary is being built on. If you were to compile Qt5 yourself on Ubuntu, you'd still run into this problem, albeit not in the statx(2) case, since it took until glibc 2.28 for that to be implemented in the C library. On the upcoming Ubuntu 19.04, this is going to be the case, though.

@fweimer

This comment has been minimized.

Copy link

commented Jan 8, 2019

Qt has fallback code for other kernels. They could do run-time detection and drop the ABI note. The Qt in Red Hat Enterprise Linux 8 has been patched to do just this, to preserve compatibility with the Red Hat Enterprise Linux 7 kernel.
Of course there is still a WSL bug here, the version really should be consistent. (Although calling the kernel 4.4 is a bit of a stretch, considering that various system calls are not implemented properly.)

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented Jan 8, 2019

Qt is not a GUI library in itself, and there's a lot of features in the library that have nothing to do with GUI or hardware abstractions

Preaching to the choir, brother. Personally I don't think any of these libraries have thing-one to do with 'graphics'. Some of the functions end up reading and writing bytes down a socket, maybe, sometimes, depending on the function.

But, sadly, this line of reasoning (most unfortunately) falls down, because of issue submissions along the lines of (say, made-up example) "VLC doesn't run I get <some libQt* function s---ts bed>". Which is, in effect, useless for tracking down syscall surface bugs. By taking libqt or say libgtk+ off the table, and limiting the scope to CLI (ie tty) scenarios, there is at least a snowballs chance of getting an actionable repro with a manageable strace demonstrating a diverge. The problem has nothing to do with pixels. The distinction doesn't really have to do with ttys either, which is why "server scenarios" are out of scope too. Made-up example would be "My Apache PHP service isn't working, I get error <whatever>". Today's necropost on some mysql EIO problem comes to mind.

You can game the system of course, and that's exactly what folks should do. Any large graphic or server scenario can be turned into a small CLI one. Chrome (about as big as it gets) used to die because getdents64() was subtly broken. People can post "Chrome is broken", and then sit back and enjoy the soothing sound of the chirping crickets. Or folks can post a CLI repro like this and have a fighting chance.

@sthalik

This comment has been minimized.

Copy link
Author

commented Jan 9, 2019

They explicitly add an assembly file with the section information and have a header that differentiates between the available kernel features it was configured with.

This being an universal issue in itself is good in a way. At some point it's bound to become a problem serious enough for WSL's vendor to fix it. Especially given Debian's and Ubuntu's preference for pulling in all possible compile-time dependencies.

Does the stripping result in any instability?

Not in practice, either. I'm running some Qt project with -platform offscreen at the very least.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

Especially given Debian's and Ubuntu's preference for pulling in all possible compile-time dependencies.

Part of the reason this one went sideways though is Qt apps, even stuff like VLC, run alright on Ubuntu 18.04 from the Store. Then it gets revealed after the fact it wasn't Ubuntu from the Store and the coffin nails came out. I can't tell you why Qt5 is okay on Ubuntu, because I never looked. But it doesn't require any stripping of .note tricks on WSL, even if the WSL vDSO is getting kernel versions crossed.

$ cat /proc/version
Linux version 4.4.0-18309-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #1000-Microsoft Thu Dec 20 12:56:00 PST 2018
$ lsb_release -d
Description:    Ubuntu 18.04.1 LTS
$ sudo apt-get install qt5-default
[...blah blah kitchen sink]
$ apt-cache show qt5-default | grep Version
Version: 5.9.5+dfsg-0ubuntu1
$ /usr/lib/qt5/bin/qtpaths --qt-version   # look ma no error while loading shared libs
5.9.5
$ ldd /usr/lib/qt5/bin/qtpaths | grep libQt
libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 (0x00007f3683d20000)

I suspect (or would like to hope) this issue would have gotten more grease if qtpaths or qmake or whatever (legit CLI scenarios if there is such a thing) faceplanted on a supported Debian or Ubuntu distro. But that's not how it went down.

@sthalik

This comment has been minimized.

Copy link
Author

commented Jan 9, 2019

I suspect (or would like to hope) this issue would have gotten more grease if qtpaths or qmake or whatever (legit CLI scenarios if there is such a thing) faceplanted on a supported Debian or Ubuntu distro.

So you're saying that some recent Debian version doesn't exhibit this behavior? My sid/experimental with Qt 5.11 has this.

it doesn't require any stripping of .note tricks on WSL, even if the WSL vDSO is getting kernel versions crossed.

Qt has some dubious stuff where Qt5Core can be invokes as an executable directly too. I don't think it should exist in the tree to begin with, but of course WSL ought to support ELF binaries correctly.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

My sid/experimental with Qt 5.11 has this.

Wouldn't be surprised if your sid/experimental has a lot of things on WSL, both known and unknown. [Wouldn't surprise me if it didn't, either.]

but of course WSL ought to support ELF binaries correctly

Probably. Depends on whether reporting 3.14.11 was deliberate, presumptively because lying in the vDSO and reporting 4.11.n would break other stuff for lack of the necessary coverage to pull off the lie. In which case your ELF binary is being supported correctly for the kernel version that WSL really identifies, /proc/version fibs notwithstanding. Or whether it was just a bog-simple oversight. I can't tell you which. I even hesitate to guess. Grateful for Christian's explanation either way though.

@benhillis

This comment has been minimized.

Copy link
Member

commented Jan 9, 2019

@ChrisTX - Excellent job debugging this! Looking through the history I looks like the mismatch version in the VDSO is accidental.

I can update the vsdo to match the version number from uname and the procfs, but while I'm doing that I wonder if there's a different version that we should be reporting... 4.4.0 was a somewhat arbitrary decision, I can look through the Linux kernel release notes and see if a more recent version number would be warranted.

@benhillis benhillis added the bug label Jan 9, 2019

@benhillis benhillis self-assigned this Jan 9, 2019

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented Jan 9, 2019

4.4.0 was a somewhat arbitrary decision

One (arbitrary) gate on bumping to 4.11 might be statx(2) (sycall 332). Dunno if we have that yet; it's never come up AFAICT (cred Chris for pointing it out).

@ChrisTX

This comment has been minimized.

Copy link

commented Jan 10, 2019

I can update the vsdo to match the version number from uname and the procfs, but while I'm doing that I wonder if there's a different version that we should be reporting... 4.4.0 was a somewhat arbitrary decision, I can look through the Linux kernel release notes and see if a more recent version number would be warranted.

If it helps you can find a table of all syscalls and when they were implemented in syscalls(2).

As for the version, as @fweimer mentioned, it's "not really a version 4.4.0" at the moment, for example msgget(2) still being missing (#1443). I suppose outside of assumptions that a given kernel version corresponds to a set of syscalls being available, there's no difference to WSL.

It's worth nothing though, that with Kali Linux in the store, and Arch being available by other means, some very recent userlands have been tested by people, the 4.4.0 report seems to cause few issues other than with Qt5. In the Wiki of "ArchWSL" for instance, there's a list of know issues and it boils down to the absence of msgget(2) breaking fakeroot and this very issue with Qt5. As I've mentioned above, LSB specifies the use of the .note.ABI-tag section, but it sees very little usage.

Conversely, if you bumped the version, this would affect the calls preadv2(2), pwritev2(2), copy_file_range(2), the pkey_mprotect(2) family and statx(2). Outside of pkey_mprotect(2), the calls can be emulated by glibc with some degree of comprise.

One (arbitrary) gate on bumping to 4.11 might be statx(2) (sycall 332). Dunno if we have that yet; it's never come up AFAICT (cred Chris for pointing it out).

I've checked in detail, with the statx test from the kernel and it's not implemented.

Qt works nonetheless as found on Arch (which is built with it enabled), because they've relegated the statx(2) and renameat2(2) calls to the glibc wrappers (with the former being available since 2.28), and statx(3) approximates the call if the former is not available in the kernel.

I can't tell you why Qt5 is okay on Ubuntu, because I never looked.

It's because this only affects Qt5 version 5.10 and newer, it was introduced with this commit.

But I would consider the issue specific to Qt here not a direct problem of WSL: as @fweimer mentioned, there's better solutions for this check, and since a Linux kernel may receive backports, concluding that because a certain kernel version was found, no features from a newer one are available is simply not true with RHEL around. Or in the same way, it will still work with older kernels if glibc >= 2.28 is being used, since the wrapper emulates it.

@therealkenc

This comment has been minimized.

Copy link
Collaborator

commented Jan 10, 2019

it's "not really a version 4.4.0" at the moment, for example msgget(2) still being missing
the 4.4.0 report seems to cause few issues other than with Qt5

sync_file_range(2), memfd_create(2), mincore(2). That's not counting stuff like clone(), ptrace(), prctrl(), setsockopt() being a big all-singing-all-dancing meta-syscalls bounced off magic option&flag redirects. (Don't get me started on /proc.)

Awkward because there's precedent for both overstating and understating the WSL kernel version. There's no right answer. The author of that ArchWSL known issues Wiki page just picked their personal pet peeves (Qt and, utterly at random, fakeroot). Different folks have different peeves, with plenty to go around.

But your conclusions are absolutely right. Great synopsis. There isn't much point in exaggerating the kernel version, and good reasons to not.

@ChrisTX

This comment has been minimized.

Copy link

commented Jan 10, 2019

The author of that ArchWSL known issues Wiki page just picked their personal pet peeves (Qt and, utterly at random, fakeroot).

fakeroot is quite quintessential on Arch, because the makepkg tool to build packages from a PKGBUILD source heavily relies on it. Without it, it's impossible to build your own packages and thus install anything from the AUR user repository. If you were to use the dpkg-buildpackage tool on Debian/Ubuntu, you'd need it for the same reason.

My point wasn't that there's not a number of syscalls broken or bugs in WSL, but rather that even on a rolling userland like Arch, the most common issue stemming from the 4.4.0 version is this .note.ABI-tag issue. I've naturally experienced some issues due to emulation, like some threading tests for libc++ failing, that I still need to debug in detail when I've got time, but as far as the kernel version is concerned, it should be only this issue.

@rigarash

This comment has been minimized.

Copy link

commented May 1, 2019

FYI, Debian 'Buster' release, which will be released within a few months, will be affected by this bug.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927940 for the discussion in Debian.

@py563

This comment has been minimized.

Copy link

commented May 8, 2019

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.

@py563

This comment has been minimized.

Copy link

commented May 10, 2019

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.

plfiorini added a commit to lirios/settings that referenced this issue Jun 10, 2019

Update Jenkinsfile
Put several commands together and try to make libQt5Core.so work
on Docker [1][2]

[1] = https://github.com/dnschneid/crouton/wiki/Fix-error-while-loading-shared-libraries:-libQt5Core.so.5
[2] = microsoft/WSL#3023

[ci skip]
@sthalik

This comment has been minimized.

Copy link
Author

commented Jun 21, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.