3

after extracting so much useful information from this community I finally decided to join this one as well.

I have a specific question about the procedure to upgrade glibc. Yes, I know this is 'risky' and probably a bad idea, but it should be possible right? There's another question here: libc 2.29 on buster but it doesn't seem to have a reliable answer. My question isn't specific to 2.29; for example I'm trying to install 2.32.

glibc is compiled by my cross-compile toolchain (crosstool-ng) using the armv6-unknown-linux-gnueabihf template. Due to a bug in the 2.28 compilation of glibc there that I cannot seem to solve (see: github), the other option I'm left with is upgrading the glibc version on the target.

I tried replacing the libc.so in the rootfs by just mounting the SD card to my linux host machine (so no program would be using libc) but then mayhem occurs. The pi seems to boot just fine and responds to pings, but ssh'ing for instance becomes impossible.

I'm hoping for someone with a little more experience on the matter that hopefully points out the obvious thing I'm missing here.

Improve this question
5
  • 1
    As someone who's been compiling software on linux for something like several decades: If you need a system with 2.32, find a distro built on it -- there probably aren't many explicitly for the Pi and hence you may need to adapt a generic armv7/8 (multicore models -- single core you'll be out of luck) for use on the Pi. That's a bit technical, but not too hard, and I think commonly enough done (as opposed to manual replacement of libc, which is crazy), so bluntly: Trying to upgrade libc on Raspbian is the the Y side of an XY problem...
    – goldilocks ♦
    Commented Dec 10, 2020 at 18:29
  • 1
    ...where the X is install an OS running 2.32. Put another way: If it is too challenging for you to adapt a generic ARM linux distro to work on a Raspberry Pi, then you have no chance of getting a libc upgrade to work on Raspbian. And 99% of people who felt confident doing the former would not bother thinking about the latter even if they did think the chances were good (probably a very small crowd), which is why no one would do this, and if you feel you have no other choice, that's "painted into a corner" (in reality, nothing you can do will work).
    – goldilocks ♦
    Commented Dec 10, 2020 at 18:29
  • Thanks, exactly the kind of advice I was looking for! I really want to know more about linux's inner workings but in 2020 the curve seems to be steeper than ever with all these high level languages and abstractions. I will try something like this soon (I found: linuxfromscratch.org which also comes with a nice reader). In the mean time I did solve this particular problem by copying the compiled libc and ld-linux (they are compiled by crosstools-ng) to a separate folder on the target and changing the libc and ld-linux my executables are using by utilizing patchelf.
    – YVbakker
    Commented Dec 11, 2020 at 11:51
  • So basically I have two versions of libc installed currently. Unfortunately I can't upvote your comment yet otherwise I'd have done so! Thanks for your advice
    – YVbakker
    Commented Dec 11, 2020 at 11:57
  • @goldilocks would you mind writing a short answer so I can mark this as solved? I don't know how to do this otherwise or perhaps a moderator should do it for me
    – YVbakker
    Commented Dec 11, 2020 at 12:02

1 Answer 1

Reset to default
4

The Pi can still boot because the kernel does not use userspace libraries, so it's unaffected. However, almost every userspace Linux program uses glibc, so when you replace that library, you will break programs which happen to use any functions which are not compatible anymore.

In general, it's helpful to look at glibc compatibility chart, even though it applies to amd64 version of the library. There appear to be big changes between versions 2.29 and 2.30, affecting even the most basic functions such as open(), and version 2.32 brings even more differences to the table.

Short of recompiling the whole Pi OS with the new library, you won't be able to use it. You might create a chroot environment with a different glibc, and run your code inside that environment, but I assume that's not what you want (you'll have to populate it with libraries and tools all built against the new glibc!). If you plan to distribute binaries which are supposed to work on stock Pi OS, you'll have to get the right glibc in your toolchain.

Improve this answer
2
  • 1
    Thanks for the further elaboration and pointers (no pun intended) this has been very helpful. I’ve moved from crosstool-ng to buildroot which gives me a lot more control
    – YVbakker
    Commented Dec 18, 2020 at 14:39
  • 1
    @YVbakker Thanks. As a side note, learning how poor binary compatibility is in Linux made me really appreciate all the effort Microsoft has put in their products to achieve such remarkable compatibility across Win32 ecosystem, which most people take for granted.
    – Dmitry Grigoryev
    Commented Dec 18, 2020 at 15:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.