Hey so if you suffer from my kind of brain damage, and decide it'll be a great idea to start compiling things against musl libc instead of glibc be warned:

If you repoint `usr/lib/libz.so.1` to the latest zlib compiled from source linked against glibc, everything works fine, but if you use the latest zlib compiled from source linked against musl libc, you'll boot loop right after lockscreen entry (which for me also failed to load the themed buttons for the lockscreen).

I hope I don't need to remind anyone engaged in such shenanigans that you'll want

1. power kernel with fbcon (or whatever you kids these days are doing for kernels on Maemo 5, so long as it has the framebuffer console modules),

2. the `/sbin/preinit` modication that will let you drop into a root shell at the earliest part of the boot process, and

3. to backup everything, or at least the library you are modifying - I was only able to get back to a working state because I saved my original glibc-linked `/usr/lib/libz.so.1.2.11` as `/usr/lib/libz.so.1.2.11.bak`, and so I was able to do a couple of `mv` commands and get back to a booting system.

P.S. Also more generally, musl "coexists" just "fine" with glibc but only because glibc sits at `/lib/libc.so.6` while musl only wants to sit at `/lib/libc.so`, until you want to compile against glibc again, and also if you still have glibc headers lying around you'll occasionally get mysterious configure/compile errors, but anyway when you start recompiling libraries that other glibc-linked binaries on the system link against, it's going to become a very unpredictable mess of "will it work?" very quickly.

P.P.S. My current plan is to proceed by renaming the musl-linked zlib and its symlinks so that the first number after the .so is a 2. And then edit the binary itself, to change the SONAME to libz.so.2 instead of libz.so.1 (this can be done with any editor because `libz.so.1` occurs in only one place, the SONAME, so long as you're absolutely sure you changed exactly just that `1` to a `2` and didn't change anything else). This will allow all the existing binaries (which link against `libz.so.1`) to keep using the glibc-linked zlib while I think all new compilations on-device will use the libz.so which will now link to libz.so.2, so new things will be compiled to use the new one.

P.P.P.S. Maybe don't try to retread in my footsteps? Either way it's all at your own risk, I'm not your doctor, nor your lawyer, nor your [...], this post comes with no warranties including but not limited to warranties of merchantlity or implied fitness for any particular purpose blah blah blah I'm not responsible if you brick your device or if you look back on your life after spending years occasionally recompiling binaries from source on your N900 and realize you've wasted your best years and your children no longer love you or whatever.

Thanks for that. But you lost me somewhere along the lines of the fourth glibz or was it musl.so or libgc.6

Good to know you are alive and active...

Good to read you again!

Why musl? it is just because of the space?
Every time I see something compiled with musl (e.g. alpine linux) there's something not quite right or just plain wrong..