<aggi>seems there is no way to avoid GNU binutils, besides it's AS required for libc, too RANLIB isn't available with a tcc-toolchain <aggi>"archive with such a [ranlib] index speeds up linking to the library"; i'll try to export RANLIB=/bin/true and see what side-effects this has <aggi>currently, it is only kernel (gcc), and musl-libc (binutils, gcc), which prevent full removal/replacement of GNU toolchain with tcc-toolchain <aggi>i'll test next what is affected by RANLIB <aggi>tcc -ar required some tiny wrapper script to avoid problems, otherwise everything seems to compile/link with AR=arm-tcc-ar wrapper too now <aggi>and today, i'll boot an aarch32-test.img firmware compiled/linked with arm-tcc toolchain, which contains ~600 builds, and only musl-libc and kernel placed onto exception for GNU-toolchain <aggi>stupid me: "ranlib is completely equivalent to executing ar -s" <stikonas[m]>oriansj: what's your opinion for hex0 code, inline 24 bytes called twice or have 25 byte function and call it twice (which I guess adds another 10 bytes)? <stikonas[m]>I think inlining might make sense even if binary is bigger <Hagfish>hmm, i'm interested to hear what oriansj's preference is <Hagfish>(my instinct is that function calls are a familiar way to structure code, but the constraints/aesthetics for hex0 are probably not what i'm used to, and the "rule of 3" would suggest it's not worth adding the extra abstraction of a function call if something is just run twice ***achaninja_ is now known as achaninja
***saksophony_ is now known as saksophony
***alethkit_ is now known as alethkit
***unmatched-paren_ is now known as unmatched-paren
***lh_ is now known as lh
***mateusz1 is now known as mateusz
***monadgauge_ is now known as monadgauge
***blockhead_ is now known as blockhead