IRC channel logs
2025-01-25.log
back to list of logs
<aggi>that's amazing if both pandoc/haskell and ghostscript can be salvaged <aggi>TeX is yet another concern, i'll just keep that in mind i didn't succeed yet when verifying any implementation with the no-c++/tinycc/linux24 profile <aggi>it's not an urgent blocker, because tinycc can bootstrap GNU/c++/, and with it any TeX implementation desired <stikonas>pandoc is not really essential for modern distro <stikonas>is GCC 4.9 basically required to build hugs? <stikonas>oh there are patches to build it with newer GCC... <stikonas>hmm, though it's not easy to build it outside Guix... <fossy>i tried for maybe half an hr yesterday to build GHC 4.09.1, appears it is non-trivially uncompilable with modern GCC too <fossy>if i'm reading the Guix declaration correctly, they use GCC 2.95??? <fossy>i got it to go a bit of a ways with GCC 4.0.4 from live-bootstrap <stikonas>yeah, I don't think I'll be able to easily create gentoo overlay like I had for mrustc/rustc... <stikonas>fossy: well, 4.0.4 can't build unpatched hugs98... <stikonas>crt1.c:(.text._start_c+0x17): undefined reference to `main' ... <stikonas>that doesn't sound like something caused by GCC version <Googulator>homo: and if anyone knows how to bootstrap Haskell, it's him, considering that *he was the one who did it* in the first place <homo>Googulator considering microhs is in active development and every month (if not every week) there is new feature, it won't be surprising if old ghc versions can be dropped <homo>at least that way it won't be painful to bootstrap on riscv (when ghc finally supports it) and arm <Googulator>Lennart wrote the original LazyML environment and the HBC compiler, which was then used to bootstrap GHC <Googulator>unfortunately that bootstrap chain is unusable for us today because 1. LazyML's bootstrap is itself lost (0.99 is the earliest surviving version, and it already requires LazyML 0.95 or newer to compile it), 2. all versions of GHC that could be built with HBC are lost, and 3. the entire bootstrap was carried out on a now extinct mainframe <homo>honestly I am surprised by amount of cooperation, also if ghc is really written conservatively, it's possible to patch relevant source files of ghc that microhs doesn't understand <Googulator>BTW, GHC 9.12 supports riscv, although no official binary packages are supplied yet <Googulator>bootstrappable.org last got a real update in 2021... <Googulator>it doesn't mention live-bootstrap, and it hasn't even updated for Guix's full source bootstrap achievement <homo>btw, what about nhc98 is guix? should it be dropped entirely or should it be properly bootstrapped? <Googulator>I don't know - AFAIK it was only included for bootstrapping purposes, which were never realized <Googulator>also on bootstrappable.org: "Maintaining GCC version 4.7" <Googulator>4.7 was the last version without C++ code in it, but 4.6 was the last modular release <ludocode>Googulator: Where is the GCC 4.6/4.7 work going on? Is there a public repository for it? <stikonas>well, modular release only makes tarball smaller <stikonas>other than that I dont' think 4.6 vfs 4.7.4 makes much difference anyway <stikonas>4.7 doesn't unlock any new kernel versions <stikonas>GoogulatorMobile: have you tried building hugs outside guix? <homo>stikonas hugs is already package outside of guix in several distros <stikonas>I can probably check if they have some extra patches to build on modern system <homo>there is nothing fancy about building hugs on modern system, just one patch to inline <stikonas>homo: hmm, strange, I'm getting some build errors <stikonas>yeah, people here have seen blynn compiler for a while <stikonas>ok, let me generate build log with this patch <stikonas>I think hugs itself builds but something is wrong with the libraries <stikonas>it does look to me like it tries to build .so library as a normal binary <stikonas>but of course it doesn't have main() function, since it is supposed to be a library <stikonas>if I manually pass -shared to that gcc command then it does build .so file fine <stikonas>well, I can workaround this particular issue by adding "-shared" to #define MKDLL_CMD in ./src/config.h but there are some other issues even with this fixed <stikonas>ERROR "../libraries/bootlib/Foreign/Storable.hs":149 - Undefined type constructor "HTYPE_INT" <homo>stikonas I really have no idea, it seems to be problem caused by autoconf, I am too scared to touch that <homo>stikonas to get ../libraries/bootlib/Hugs/Storable.so you need to run: ffihugs ../libraries/bootlib/Hugs/Storable.hs <homo>honestly I don't even want to know why autoconf, automake, configure, cmake, meson, scons, waf were created when it is easy to write portable Makefile or mkfile <homo>hugs should be forked with all that autohell removed and replaced by plain simple Makefile or mkfile <homo>I bet there is already mkfile for plan9 as hugs is ported there, just needs adjustment for other platforms <homo>people must really hate declarative programming when they don't write Makefile nor mkfile <stikonas>well, it is posible to write Makefiles, but it's not necesserily easy <stikonas>I've seen people making huge mess out of Makefiles... <stikonas>Makefile is closer to assembly in programming <stikonas>whereas cmake or meson are like higher level languages <homo>Makefile is not closer to assembly, quite the opposite <homo>just state your dependencies and write instructions to create those dependencies, problem solved <homo>and it scales on multiple processor cores quite naturally <homo>it mixes declarative and imperative programming <homo>entire microhs builds with nothing more than Makefile and is cross-platform <homo>hugs is not rocket science <stikonas>but especially if you look into some big monorepos... <homo>big monorepo - entire plan9 and inferno use mkfile <stikonas>in live-bootstrap we wrote simple makefiles for quite a few GNU and some other tools (perl in particular) <homo>hell, plan9 easily cross-compiles itself to all machines using mkfile <stikonas>well, cross-compilation is more to do with the compiler <stikonas>yes, you need to pass some flags or use other binary <stikonas>e.g. M2-Planet binary can create executables for quite a few different platforms... <homo>mkfile in plan9 is declared enough to know how to cross-compile to every machine <homo>and if you read it, it is actually very elegant <homo>no tricks, everything simple <homo>build system manages dependencies, you still need it to produce non-conflicting names for all machines at the same time <homo>looks similar minus cross-compilation, but considering that is bootstrap it doesn't make sense to cross-compile <homo>because if you wanted to cross-compile to arm, riscv, power, mips and so on at the same time, how would you solve race condition like riscv binary replacing arm binary? <homo>in plan9 mk assigns unique names to binaries (because mkfile is declared so) and on "mk install" puts them into /i386/ /arm/ /sparc/ /mips/ and so on (again because mkfile is declared so) <stikonas>yeah, I didn't try to cross-compile but I did try those makefiles on riscv natively and it worked <homo>but this is also for bigger picture, as you can share same disk between multiple machines with different architectures <homo>it's distributed os that is <homo>forget what I said about hugs on plan9, nobody bothered to write mkfile for it, it uses ape (ansi posix environment) with ugly configure script, even worse not even base package is there, so it can't bootstrap microhs