IRC channel logs
2026-02-24.log
back to list of logs
<aggi>sigh, dev-libs/elfutils is the WORST build backported to TinyCC/Linux by far <aggi>a typical RedHat monstrosity <aggi>thing is, dev-lang/perl-5.36 perlcross does need readelf <aggi>and i do want a test-run _without_ binutils involved at all <aggi>so that's two monstrosities at once which block(ed) almost everything, since perl is needed by autoreconf for example <aggi>i'll just install elfutils prefixed with eu-[ar|ld|readelf|...] proposed by the ebuild already <aggi>and then this will catch all other builds which pull AR=ar instead of AR=tcc-ar (even when that's passed in ENV) <aggi>and i did notice already, there's a tendency AR=tcc-ar could have been ignored by various autoconf/automake <aggi>for that matter i think the legacy perl-5.8.6 version did not need readelf/binutils|elfutils <aggi>but i've confirmed full cross-compilation support with perl-5.36.0 only <aggi>the elfutils hack ensures the system-profile can fully transition to a tcc-toolchain only system-integration (except perl-5.36/cross currently) <aggi>besides kernel bootcode.S pieces that's the last major todo remaining; next i'll re-iterate over live-bootstrap to spawn TinyCC/OS from this <aggi>ok, perl >>> Source configured ... without binutils <aggi>although i am not pleased with elfutils-readelf, there is no way around any with perlcross to avoid type size defintions manually set <aggi>no clue who autotools determine type sizes without readelf <aggi>i think elfutils themselves which i picked an older version is the only ebuild where binutils-ar slipped through ignoring AR=tcc-ar <aggi>because at that time autotools did not support AM_PROG_AR or AC_PROG_AR - which is weird <aggi>autotools test for the entire toolchain (cc,ld,.. etc) but missed ar <aggi>and i guess that's a rare test-case binutils are completely wiped while compiling a system <aggi>thinking of a binary propagation attack, of cause it must be ensured AR= is used as what it was defined <aggi>but autotools/autoconf/automake missed that, assuming AR=ar is always there and it's not ARCH-specific <aggi>it's just paranoia, AR could misbehave in this regard <aggi>not important, but elfutils was the WORST backport ever, just to support perl-cross <nimaje>doesn't autotools normally create small test programs using sizeof and printf to determine the size of types? <aggi>yes nimaje, but those tests cannot be executed when cross-compiling for a different TARGET <nimaje>does autotools even support cross-compiling normally? <aggi>yes, although thats badly maintained rather often <aggi>otherwise, that's the principle idea with autotools, to support cross-compile <aggi>perl-cross passed. ok, i can spawn a complete system-recompile now, without gcc and without binutils, and elfutils are masked with eu-[readelf,...] prefix <aggi>so, nothing will slip-through this time <aggi>i still have in mind to separate autotools-related packages to spawn a minified TinyCC/OS release variant without them <aggi>because, GNU autotools/toolchain dependency-graph is gigantic <aggi>aboriginal-linux made an attempt almost 10years to keep a self-hosting compiled *lunix as small as possible <aggi>one reason i hesitate: i've seen many other packages which exclude autotools (cdrtools, busybox, tinycc etc.) whose build-system finally wasn't much simpler or less painful than autotools often <aggi>nowadays the trend seems to be python/meson... which is misguided, imo - since autotools do exist and won't vanish anytime <aggi>so python/meson added even more clutter atop <nimaje>wasn't the idea of autotools to provide portability, by doing stuff like checking for functions and their interfaces and sizes of types, but still compile on the target system or some compatible system (older cpu arch, …)? <aggi>yes, and autotools often does a good job with this, when configure.ac/makefile.am are maintained to meet quality standards <aggi>and most important, most of the autotools dependencies are covered by POSIX (except perl with autoreconf) <aggi>for that matter, python is not covered by POSIX either, so i don't see a benefit with meson in this regard either <nimaje>that was in resopnse to "that's the principle idea with autotools, to support cross-compile" <aggi>well, yes, and perl does not use autotools but some custom hacks with readelf involved <aggi>doesn't matter, it just builds up a problematic dependency graph for cross-compiling scenarios <aggi>and bootstrappable does not switch ARCH so it's a non-issue in this context <aggi>i'll have to do some bureaucratic tasks next days, but since all other blockers were coped with i'm excited already to do the REAL live-bootstrap thing soon, to spawn TinyCC/OS with it <aggi>which will not involve binutils/gcc at all then - that's the main difference <aggi>it will however bootstrap the forked gentoo-portage/tcc - which then can crossdev all else <lanodan>Yeah, sadly autotools merely allows to support cross-compiling, it's a very loose framework so there's a bunch of configure scripts that execute conftest code they just compiled on the host <aggi>"only works reliably for a minimal set of packages", yep, it's been a major issue with TinyCC/OS to fully support cross-setup with it for all packages bundled <aggi>another reason why i hesitate to transition to another non-portage/packaging without python involved