IRC channel logs
2025-12-27.log
back to list of logs
<aggi>fighting with static perl-cross to retain some latest perl-5.36 with tinycc, required by autotools <aggi>it's several cross/build scenarios and versions <aggi>what i got stabilized is perl-5.8.5.static with tinycc, but this doesn't support cross-compilation <aggi>i too got a perl-5.36.0.static non-cross, and a perl-5.36.0.dynamic cross-compiled <aggi>but these aren't suitable for the gcc<->tinycc toolchain swaps, which require static <aggi>complicated? to keep it brief, perl-5.36.0.static is buggy when cross-compiling, but that's the one i want to keep <aggi>it's not installing some <Module>.pm when that got a related Module.<so|a>, because XSLoader assumes it only can pull in modules as .so <aggi>strangely then, the perl-cross scripting does emit <Module>.a and links it into perl.static, but skips various <Module>.pm for installation <aggi>skipping the details, the build-system is crazy: perl+perl-cross+ebuild+patching <aggi>and this got a political aspect too, imo <aggi>because GNU, that's autotools, which implies autoreconf for compliance with bootstrapping <aggi>but there is no perl.static cross available <aggi>i have an idea though, to stabilize this, by manually copying the missing <module>.pm into install-target, since i can't wrap my brain around the build-system chaos to do it the right way <aggi>this nonsense had cost me several sleepness nights already <aggi>can't rule out a mistake of mine, i tried my best so far <aggi>perl isn't blocking the gcc<->tinycc transitions, it's blocked by static cross-compile <aggi>seems to me, noone else has ever tried this in more than 10years <aggi>for that matter, i would prefer to hack perl-5.8.6 for cross-compilation support than hacking static perl-cross for perl-5.36 <aggi>makes me wonder, why perl-5.8.6 didn't support cross-compilation <aggi>static/cross is another corner-case, seeing to how "portable" POSIX/Unix/GNU/BSD really was <aggi>sh4: wanted to ask you something <aggi>how did sabotage linux cope with perl/static/cross/autotools? <aggi>as for GNU, it relies upon autotools almost everywhere. how didn't perl then support static/cross? <aggi>among others, it is THE corner case to confirm portability <sortie>aggi: Oh my! You seem to be working on exactly the same problem that we solved just yesterday! <sortie>aggi: The lack of modules happens because 'make static' does not invoke all of the module makefiles, so you need to inject a 'make pm_to_blib' as well before that point in the makefile. I was just cooking up a commit that fixes the problem on my end, then I can show you my work :) <sortie>Perl static linking is pretty darn bitrotted out of the box it appears <aggi>sortie: that's confusing, because perl-cross does compile the related <Module>.a files but skips related <Module>.pm <aggi>staring at perl-cross/Makefile truly seems amazing work, no clue yet how to repair this even with the hint given <aggi>such as, Cwd.a is bundled, and Cwd.pm is missing; to it seems pm_to_blib is called inside Makefile <aggi>File/Glob, File/Find, and a few more, nonsense <aggi>the workaround i got is perl-5.8.6 which doesn't support perl-cross <sortie>Not the latest versions, it took us a while to get around to debugging perl (since it's build system is so absolutely terrible, it was super hard to debug what was missing) <sortie>The problem, as far as I understand, is that the static linking makefile logic doesn't actually invoke pm_to_blib for each of the modules. That means that C source code modules got built propertly, but perl source code modules did not <sortie> $(static_modules): %/pm_to_blib: | %/Makefile $(nonxs_tgt) <sortie> $(MAKE) -C $(dir $@) PERL_CORE=1 LIBPERL=$(LIBPERL) LINKTYPE=static static <sortie>+ $(MAKE) -C $(dir $@) PERL_CORE=1 LIBPERL=$(LIBPERL) LINKTYPE=static pm_to_blib <sortie>Specifically this little addition appears to fix that problem. You can also see how I solve a lot of other static linking and cross-compilation issues in my patch. I'm hoping to upgrade it to the latest upstream versions soon, but for now, I'll just make sure this fix is stable and fixes my problems :) <aggi>thanks alot sortie; i guess something's a little different here, installperl merely missing related .pm files <aggi>sorry, takes a little while <aggi>its wrapped into the whole gentoo-ebuild crazyness here <aggi>and i tend to prefer perl-5.8.6, it's sufficient still for GNU/autotools, it does work already, and it too may support cross-compile <aggi>seeing all this, raises a huge question mark over entire Perl and GNU <sh4>aggi: there's a project called perl-cross which we use to get a proper build system for perl <sh4>ah, sortie already mentioned it <aggi>sh4: it's static+perl-cross <aggi>sh4: since you're here, by coincidence, is your nickname related to SH4/jcore? <sh4>well, you wouldnt even need perl if it wasnt for gentoo's portage <sortie>Well perl bypasses the whole GNU autoconf system and doesn't reinvent it well, which is why stuff goes bad, so no blame on GNU in this particular case <aggi>nope, perl is required for autoreconf which is an acceptance-criteria of bootstrappable, and a reasonable sanity check <sh4>aggi: it's a coincidence, but one i dont mind - since imo sh4 is one of the best cpu designs <sh4>well, i usually work my way around auto-reconf by patching configure directly <aggi>gentoo relies upon python, which too caused major headache for python.static cross-compiled with tinycc, but this one is done <sortie>Yeah perl is in the set of all packages needed to build all packages, at least for my custom OS and my choice of packages, and that is why I really, really need it to be cross-compilable for bootstrap reasons (and why it's so maddening to see it being one of the worst packages for that purpose, and even perl-cross isn't that good, but it does get me much of the way, and I could complete the job) <aggi>ok, (perl-compilation is slow, so this chat runs in parallel) <aggi>to keep it brief, there is a more or less easy way around python/portage, thats how sabotage linux packaging is interesting for example <aggi>but there is NO way around perl/autoreconf <sortie>There's probably a few gems in my perl.patch that would benefit from being upstreamed to perl or perl-cross <sh4>you'd be amazed how far we got without perl <sortie>Like, I just fixed some cross compilation issues in Time-HiRes <sh4>you can build the entire base system, with kernel, but without perl. only when it gets into the X/Desktop packages it's no longer optional <aggi>sh4: the ideal scenario i see is, avoiding python, avoiding perl, avoiding portage, avoiding autotools <aggi>but as soon as there is some makefile.am, i rather follow bootstrappable.org recommendation, to confirm autoreconf, that needs perl <aggi>or, and that's the mega-task, re-writing entire packaging of GNU without autotools/perl <sh4>imo it's better to hack the existing configure script than configure.ac - though some very annoying packages dont even ship a configure script anymore <aggi>which there's some efforts for, with meson for example, but this swaps one devil for another, python in this case, and not desirable <aggi>the least pain i see, is keeping perl (static/cross, tinycc, depends on scenario), and with it GNU autotools <sh4>they just put a tag on their git repo and leave you with the github-tarball-from-tag without any generated files <aggi>i've patched entire portage-tree that i forked, to run autoreconf, just saying <sh4>there's muon which i keep my eye on, but i still couldnt convince its author to add proper POSIX-style cross compilation <sh4>yeah, i know the pain <aggi>and i can keep this running already, with perl-5.8.6.static tinycc-compiled, but not cross-compile <aggi>but i do fear, GNU might have some stupid idea, to drop perl-5.8.6 and later depending on some recent perl version <aggi>so, i rather confirmed perl-5.36.0 in advance, if this ever happened in the future <sh4>fortunately nobody codes in perl anymore, so i doubt they will bump the requirements <sh4>otoh i take perl over rust a hundred lifetimes <aggi>sortie: seems your suggestion worked, although i had to change a little more to just make it work(tm) <sortie>What did you have to change additionally? <aggi>that's good news, and rather important, because entire GNU depends on it <aggi>sortie: there's a whole ebuild+patching-chaos, and as for your change i guess this might suffice: <sh4>aggi: i'd personally focus on getting tinycc to work mith musl's ld.so <sh4>static perl and python are really crippled <aggi> $(static_modules): %/pm_to_blib: | %/Makefile $(nonxs_tgt) <aggi>- $(MAKE) -C $(dir $@) PERL_CORE=1 LIBPERL=$(LIBPERL) LINKTYPE=static static <aggi>+ $(MAKE) -C $(dir $@) PERL_CORE=1 LIBPERL=$(LIBPERL) LINKTYPE=static static <aggi>+ $(MAKE) -C $(dir $@) PERL_CORE=1 LIBPERL=$(LIBPERL) LINKTYPE=static pm_to_blib <aggi>sh4: i do consider dynamic-linking important, it's just not highest priority as is perl/autotools <aggi>and for some weird reasons, by coincidence, i consider full static-linking support and full cross-compilation support important <sh4>static linking only gets you so far <aggi>currently i'm in the middle in between cleaning up a gigantic git-workspace to commit, that's the technical hindrance to git-push <sh4>it's game over as soon as you reach stuff that requires some python modules or X11 drivers <aggi>sh4: i got python.static bundled, including cross-compilation with either tcc or gcc <aggi>with this threading support is flaky, but i do not need this, because i only use pythong for portage-tooling, and this passed already, self-hosting even <sh4>yeah, we had it static at some point too, but it doesn't support modules written in C <sh4>basically you'd have to shoehorn them all into the python build process if you need them at some later point <aggi>i did hack a few things, maybe that's good enough (except threading) <aggi>but other than technical hindreances to cleanup this f*** chaos inside fully forked portage tree, there's a few political nuisances too <sh4>hmm, i dont recall having any issues with python threading - though we compiled python 2.7 with gcc <aggi>which p**sss me off for a little while <sh4>(the static variant) <aggi>for that matter, i would even consider a rollback to python-2.7 with an even older gentoo-portage version <sh4>what sort of nuisances ? <aggi>but this will get me into trouble with recent EAPI versions, and i do appreciate tracking upstream portage for latest software versions <aggi>i'm syncing once a year, so it's all up-to-date, backported onto linux2 sysvabi with tinycc.static <aggi>sh4: to keep it brief, i'm being told here by hundreds of employers and dozens of universities all my work and studies are uselss <sh4>why linux2 btw ? you aim to keep gcc out of your system ? <sh4>for the record, the newest LTS kernel i added to sabotage is 6.1 and it builds fine with gcc 6.5.0 <aggi>sh4: because i seeked a _complete_ system integration with any alternative C(!)-toolchain such as tinycc <aggi>well, i did keep gcc-6.5.0 for aarch32 (i tried to keep a few more test-vectors covered other than tinycc/linux2) <sh4>i'd wager that you could get e.g. kernel 4.19 to build with gcc 4.7.4 still <aggi>i've even patched linux-5.9/5.10 for gcc-4.7.7 <aggi>but i couldn't pass any later than linux2 with tinycc <aggi>it's all documented on my test-site, as for how and why all that is <aggi>there's a few more problems <aggi>i had to fork portage itself, that's blocked indefinitely, but none of my concerns anymore since gentoo didn't engage with my proposal <aggi>it's not blocking anything else, <aggi>i just can't nor won't upgrade some components anymore, such as python/portage-3.8.x <aggi>no upgrade beyond gcc-4.7.x, no upgrade beyond linux-5.10 <aggi>the linux2 kernel is interlocked with tinycc, but as said i did keep a few other test-vectors covered too <aggi>i'm not blocking any update beyond, i just won't do it myself anymore <aggi>and there is _technical_ reasons for this, unrelated to my individual opinions <aggi>which means, i can upgrade, but upstream regressed against my backport <aggi>loosing: c-toolchain portability, loosing cross-compilation support, loosing static linking support <aggi>and upstream too is extending bootstrapping system-integration chains to ever increasing complexity and length <aggi>while tinycc/linux2/static shortens the system-integration chain for a somewhat complete(!) GNUish/BSD/POSIX <aggi>at the cost, my fork can't be merged back into upstream, it's unavoidable to fork <aggi>not for GPL/licensing issues, for technical reasons <aggi>maybe *BSD are a little better off than GNU, because i think they forked their entire base-systems not relying on autotools/perl for example <aggi>but they're too locked into g++/llvm toolchains nowadays <aggi>at least, on the GNU side it's both bootstrapping and c-toolchain portability confirmed now <aggi>other than tinycc, scc compiler/toolchain etc. exists, to keep that in mind <aggi>and with tinycc/linux, it is at least _one_ *nix/GNUish system remaining, that was confirmed for portability without g++/llvm <aggi>with a _complete_ self-hosting system-integration <aggi>cross/static support is a little bonus, given this had not been sufficiently maintained and tested either <aggi>i'm not opposed to GCC/g++, if c++ remains _optional_, which it isn't nowadays <aggi>and there is good reasons not to place all bets on g++/llm with free software <aggi>the system-profile is portable towards both linux2 and linux5 still <aggi>hence, if any other kernel/version was hacked for support with tinycc (or scc, kefir, cproc/qbe whatever), there is no blocker to transition this <aggi>it's supported already, but covered by keeping gcc for this test-vector <aggi>the reason why the fork is complicated: full linux2/tinycc/static/cross support was necessary in parallel <aggi>and i don't see a chance to gentoo to re-introduce USE="-cxx linux2 static", so i had to fully fork anyway, because i am not willing to be hit by further regressions <aggi>as a consequence, there is no other system remaining known to me which got c-toolchain portability, and it can't be merged back <lanodan>Made me check again and Oasis Linux (notably ignores the upstream buildsystem) doesn't have perl, so one can have a (very) minimal graphical environment with no perl involved. <aggi>that's interesting lanodan, because Oasis to works on cproc/qbe support, but due to choice of kernel they can't detangle from g++/llvm i guess <aggi>hence i'm underlining a _complete_ system integration with c-toolchain portability to begin with, as a development baseline <aggi>migrating entire packaging to oasis-style scripting is just too much effort, and not the highest priority among other tasks <aggi>my favorite type of kernel would be some fiwix one, which some hacking was done for already by bootstrappable <aggi>for practical reasons, SATA/USB/SMP/Ethernet, i keep it at linux2 for now <lanodan>Yeah, part of me wishes for something like a fiwix-based oasis <lanodan>That said for stuff like SATA/USB/… (Ethernet… there's like 3~4 chips that matter, Internet is a big chunk though) it makes me wonder if anyone here looked into Plan9 and illumos <aggi>well, i'm banned from cat-v since recently <aggi>on technical terms, i tend to disagree with their intentional departure from posix and ansi/iso c <aggi>although it seems possible to port back-and-forth between 9front and *nix/gnu <nimaje>well, plan9s goal wasn't to make another unix, but to make a better unix, so throwing out the trash (posix and C) was unavoidable