Failing to build TOT LinuxL #470
Comments
|
flex and bison aren't in the toolchains, the airlock setup still tries to link them from your host $PATH (https://github.com/landley/toybox/blob/master/scripts/install.sh#L105) meaning it expects them installed on the host. (I do plan to provide usable lex and yacc versions in toybox, but they're on the todo list after awk and make.) I have newer toolchain builds here, I should upload them with the coming release. (Alas musl-cross-make stopped updating, so what I really should do is bite the bullet and write my own standalone toolchain build script. But the ones I have still work for me, and when I have spare toolchain brain I mostly spend it fighting with https://github.com/quic/toolchain_for_hexagon/ so... That said, I've locally built arm64 hosted versions and should upload both sets next time...) Rob |
|
I am able to build toybox for my host arch
and qemu boots as expected using:
but I'm unable to ping dns.google.com any suggestions on the best way to debug? However, I'm still seeing the same issue building for arm51:
Do you have any suggestions on the best way to debug? |
|
For the ping issue: I don't see any issues in the kernel log: |
|
Because glibc doesn't support static linking, which is why I provide musl-libc toolchains. You may have notices the warnings going past: net.c:(.text.xgetaddrinfo+0x54): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking This is a well-known glibc bug: https://stackoverflow.com/questions/2725255/create-statically-linked-binary-that-uses-getaddrinfo Because its' ex-maintainer, Ulrich Drepper, has a personal dislike for static linking so he stabotaged support for it. You fundamentally can't dlopen() from a static binary for a bunch of reasons (https://www.openwall.com/lists/musl/2012/12/08/4 and https://inbox.vuxu.org/musl/20200423022531.502e9d26@zenbook/t/ and so on). The most fundamental of which is that the "heap" that malloc() and free() track memory in is basically a global variable in libc. When you use a dynamic libc, the global variable pointing to the heap lives in the shared library's address space. When you static link, the global variable tracking the heap lives in your executable's address space. If you load a library from a static executable, you now have TWO heap pointers tracking two different heaps, and if you malloc() from one context and free() into the other, you've leaked from one heap and corrupted the other. I have part of a mkroot/packages/dynamic to do dynamic instead of static linking, copying the shared libraries from your toolchain into resulting filesystem. Unfortunately, if you do that on debian's host toolchain, it copies 1.7 gigabytes of libraries. |
|
The ping issue isn't in the kernel log, it's in the libc code. If you statically link glibc, glibc breaks. This is because glibc is terrible. And more stuff breaks over time: looking up usernames from UIDs switched to a shared library plugin, so that silently fails now and ls -l shows numbers instead of names when statically linked against glibc. The problem is glibc. This works fine with musl. Or uclibc. Or bionic. Or sufficiently old versions of glibc.... |
|
There's a little bit of explanation about this in https://landley.net/toybox/faq.html#cross1 but I mean to add a README to the mkroot subdirectory, and explaining this issue succinctly without coming out and saying "the glibc devs are INSANE" is one of the blockers... |
(note that those are just implementation details --- there's no theoretical reason you couldn't make dlopen() work from static binaries [and it seems like glibc folks may be starting to rethink this themselves] ... you just probably don't want to have to go to all the trouble. musl especially doesn't want to because musl really cares about having tiny static binaries, and -- because you don't know what's going to be needed later -- if static binaries supported dlopen(), they'd need to pull everything in. again, that's mostly an implementation detail too --- a hypothetical sufficiently sophisticated system could only do this to you if you actually have a call to dlopen() and gc everything otherwise. but it comes back to the "ridiculous amounts of work for unconvincing benefit [and massively increased testing costs]". which is one reason why bionic static binaries only have a dlopen() that always returns NULL, for example.) |
|
Indeed it's not fundamental that you can't
I've worked out a concept by which we could do static |
my assumption there, when i've [only very idly] thought about this for bionic is that we'd just ignore any libc.so DT_NEEDED. i've long been tempted by the idea of deprecating and removing libm.so that way, which is a lot less work and so might actually happen one day... but, yes, the trouble people already get themselves into with mixtures of static and dynamic for their own libraries makes me very much not interested in going down this path, and continuing Android's "static binary support is for init and the dynamic linker" philosophy. |
|
Reviewing this thread, my todo item here is being sure to upload new toolchain builds for the next toybox release, which is somewhat gated by Rich not having updated musl-cross-make in 2 years so I may need to forward port patches to newer glibc/binutils versions myself... |
|
FYI, Rich has updated musl-cross-make. I've been fighting with my arm64 build environment trying to get arm hosted toolchains as well as x86-64 ones, but have yet to boot a vanilla kernel an an orange pi 3b and I recently moved from the place where I could easily plug it into the house router. Working on it... |
I'm running:
mkroot/mkroot.sh CROSS_COMPILE=armv5l-linux-musleabihf- LINUX=$GIT_ROOT/linux
with TOT Linux and the build is failing (see below) I also don't see flex in the armv5l & armv7l toolchains from:
https://landley.net/toybox/downloads/binaries/toolchains/latest/
I note that binaries in in the above directory are over a year and half old. Anyone have any pointers to more recent toolchains
=== linux-arm
/mnt/wsl/projects/git/linux /mnt/wsl/projects/git/toybox
/mnt/wsl/projects/git/toybox
/mnt/wsl/projects/git/toybox/root/build/armv5l-tmp/linux /mnt/wsl/projects/git/toybox
HOSTCC scripts/basic/fixdep
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/confdata.o
HOSTCC scripts/kconfig/expr.o
LEX scripts/kconfig/lexer.lex.c
/bin/sh: 1: flex: not found
make[2]: *** [scripts/Makefile.host:9: scripts/kconfig/lexer.lex.c] Error 127
make[1]: *** [/mnt/wsl/projects/git/toybox/root/build/armv5l-tmp/linux/Makefile:685: allnoconfig] Error
The text was updated successfully, but these errors were encountered: