IRC channel logs
2024-07-29.log
back to list of logs
<fossy>aggi: i presume you are talking about live-bootstrap's bootstrap path; don't believe gcc-4.x does need musl 1.2 (that would be strange, given that it historically preceds musl 1.2). musl libc update is simply desirable because it is newer, and in live-bootstrap, we do not care that it breaks tcc, because we are trying to get away from tcc as soon as possible <fossy>(at that point in the bootstrap) <aggi>fossy: thanks for the reply <aggi>"we do not care that it breaks tcc, because we are trying to get away from tcc as soon as possible" <aggi>ok, let me elaborate myself <aggi>briefly, i intend to avoid gcc as long as possible, and use tcc-toolchain _only_; however trusting #bootstrappable can and did confirm gcc-bootstrappring works anytime i wanted to do this myself <aggi>unspecific to bootstrapping, it seems tcc is rarely ever tested/supported as default system-compiler anywhere <aggi>same question. why would that be? <fossy>tcc is a fairly brittle or otherwise undesirable compiler for a few reasons; 1. its codebase is horrible and very difficult to read or modify (gcc isn't amazing, but still better). 2. it cannot compile much modern software (to be fair, a fair chunk does work, but not an acceptable amount). 3. while it is fast, it does not produce particularly fast code. 4. there are many (perhaps slightly <fossy>more obscure but still) regularly used compiler options it does not have, which often makes it difficult to use with modern build systems. <fossy>5. (this is more of a personal gripe) i'm really not a fan of it's current development process (mob) <aggi>ok. for various reasons, i do maintain a complete c-only/no-c++ system profile with gentoo, and verified it passed with gcc-4.x and various cross-compilation test-cases covered <fossy>okay, i see how tcc is interesting for you then, as you have a fairly minimal system profile and tcc is small <aggi>and next, intend to fully support tcc-toolchain with this profile (for x86, and as an intermediate step with helpful gentoo tooling involved) <aggi>fossy: on the contrary, it is a rather complete and useful set of software <fossy>minimal insofar as a "typical" modern system goes <aggi>my main concern isn't neither tcc nor gcc btw.; but the GNU buildsyste itself (autotools/automake) in combination with gentoo eclasses and ebuilds <fossy>i'm not doubting that it is complete + useful (at least for your usecase) <aggi>i spare you details, what a headache libgcc.a linkage was, when cross-compiling (with gcc, musl) <sam_>on 32-bit arches you can't downgrade musl 1.2.x -> 1.1.x, I dunno about others, I wouldn't recommend it anyway <aggi>anyway, just scraped the musl-1.1.24.ebuild, and this too fails with tcc... i'm gone for a little while <aggi>ok, mus-1.1.24.ebuild just failed with CC=tcc too a moment ago, with the exact same error from musl-1.2.x.ebuild <aggi>i'll keep in mind musl-1.2.x may succeed with tcc-toolchain; it's a notable amount of test-cases since bootstrappable compiles either musl-libc in three passes, and gentoo got it's own ebuilds that i use for convenience <aggi>i see, thread-local-storage is first on the hitlist of unsupported things with musl-libc and tcc-toolchain; scary <aggi>next one, float exception handling gone <aggi>fossy: question answered why bootstrappable focused on a quick transition towards gcc <aggi>i'll see soone enough, how minimal the c-only/no-c++ profile will be with tcc-toolchain <aggi>thanks to bootstrappable patches: >>> sys-libs/musl-1.1.24 merged. <nimaje>hm, with these reasons a toolchain build on qbe, scc, cproc seems like a good idea <lanodan>Possibly that said it needs an as(1) implementation and typically that's tcc or binutils (there's minias done for qbe but it seems to be a stalled WIP).