<stikonas>at least it's written in Rust and not HVM :D <stikonas>I've actually found a toolchain that can build it (with some patches) but that's outside Guix <stikonas>(patches are probably needed because I've used GCC4) <rekado>stikonas: I can build it just fine with different toolchains including the latest GCC (with a small change), but I can’t use it with the built hugs <rekado>when I just rebuild that file with a different GCC and start ./hugs from the ghc/interpreter directory I get this error: <rekado>gs: dynamic-link.h:62: elf_get_dynamic_info: Assertion `! "bad dynamic tag"' failed. <rekado>so I guess I probably shouldn’t build that one library with a different toolchain than the rest of the interpreter. <stikonas>maybe then you can use newer toolchain for the rest of the stuff <stikonas>(but I wasn't able to get hugs to link yet) <rekado>stikonas: could you point me to those patches? <rekado>I also have a few patches for building with GCC4, but I never got it all to work <stikonas>rekado: one moment need to get them out of chroot <rekado>thanks, I’ll check them out tomorrow <stikonas>so maybe you already have somethign like that <stikonas>ok, longlong.h patch needs fixing to get linking working, (that one was just big hack) <stikonas>ok, longlong patch fixed, fewer link errors but still quite a few <stikonas>../../ghc/driver/ghc-inplace -I../includes -I. -Iparallel -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-Wpointer-arith -optc-Wbad-function-cast -O2 -optc-DCOMPILING_RTS -static -O2 -optc-fomit-frame-pointer -I../interpreter -c Assembler.c -o Assembler.o <stikonas>oh actually it's non-0 size, looked at the wrong field <stikonas>but still it's way too small 61 KB C file got translated into 625 bytes <stikonas>ok, I think workaround might be to use gcc -D INTERPRETER <stikonas>although that means I need to do more gcc4 fixes <stikonas>ok, with all those patches in https://stikonas.eu/files/ghc/ and "./configure --host=i386-unknown-linux-gnu --enable-hc-boot --with-gcc="gcc -DINTERPRETER" "make boot" "cd ghc/interpreter" "make" <stikonas>and i can at least run "./hugs --version" <stikonas>oh actually make seems to complete if I first build utils/hscpp <stikonas>there still seems to be some issue with hugs ***iridium.libera.chat sets mode: +o oriansj
***ChanServ sets mode: +o rekado_
<rekado_>but I also do additional ad-hoc patching in the Guix package definition <rekado_>haven’t been able to build the interpreter with GCC 5 (that’s the oldest toolchain I can easily use in Guix), because it fails to link hugs with the previously built RTS objects <rekado_>and building those with a recent GCC requires even more patches <muurkha>it's great that you've gotten so far! <muurkha>it'll be fantastic when we have GHC fully bootstrapped in Guix! <rekado_>it’s fun, but also really frustrating. We *have* a hugs package, but we need this modified, older hugs that comes with GHC 4 to be able to interpret the GHC 4 libraries. <rekado_>my hope is that — if I can get the GHC 4 hugs to work — we can use that to interpret the compiler sources and compile them with itself. <rekado_>I previously tried to use plain Hugs to do that, but didn’t get far because the GHC haskell sources refer to the GHC RTS. <muurkha>does GHC 4 include a modified Hugs specifically to help with bootstrapping? <rekado_>this is just so that one can have an interactive environment <muurkha>so they had to work pretty hard to keep its capabilitie in sync with GHC's <rekado_>when building the modified hugs the build system skips building of a few libraries. <rekado_>because hugs couldn’t be modified to support them. <rekado_>my hope is just that it supports *enough* to compile a few small things <rekado_>like those Haskell files that it currently skips because no Haskell compiler is available <rekado_>the former is needed for libHSstd.a, the core part of the GHC standard library. <rekado_>we may need a couple of iterations to build more of GHC 4 in each round <rekado_>the first round is just enough to build the RTS and hugs, the second to build the core standard library, the third perhaps to build the whole thing again, but with the compiler sources, etc <rekado_>I don’t think it will be possible to build it all in one go (hence my disbelief when I first “finished” building my ghc-4 package). <oriansj>rekado_: well I have faith that you'll sort it out with a good bit of work and I know that I look forward to all of the exciting possibilities this brings <rekado_>PSA: please consider subscribing to the mailing list if you want to post. I keep having to manually approve on-topic emails to keep discussions going. <rekado_>I feel like an idiot now: of course this shared library doesn’t work — because the glibc was built with --disable-shared. It’s a bootstrap glibc, so what did I expect? <rekado_>I just built it again with --enable-shared, and now I just need to mess around with the linker wrapper <muurkha>the vast majority of bugs are simple things like that when you get down to it <muurkha>it's just that the space of possible simple things that could cause a given bug is vast, so it takes a lot of work to figure out which one it is <rekado_>whee! So … now it won’t take long until we know if we can interpret the GHC compiler sources <stikonas>rekado_: oh nice to hear that! I've got hugs to build but as you might have seen from the paste, I was getting some assertion failures <stikonas>you are not geting those with your build? <rekado_>stikonas: nope, no assertion failures <stikonas>it might be that your patches are better and I broke someting <rekado_>with my patches to the C sources I also got a broken hugs. It would crash on putStrLn "hello". <rekado_>I overrode the search path and preprocessor, so I can already load some of the GHC sources, but it seems that the biggest obstacle is that GHC and hugs use different parsers. <rekado_>so I can’t interpret all of the standard library, which the GHC sources depend on <rekado_>simple example: ERROR "PrelAddr.lhs" (line 37): Syntax error in input (unexpected symbol "#") <rekado_>that’s: data Addr = A# Addr# deriving (Eq, Ord) <rekado_>IIRC in GHC that is for expressing boxed values(?) <stikonas>yeah, it's not easy for me to tell what's going on since I don't know any haskell... <stikonas>is it too much to patch out those # symbols? <muurkha>rekado_: you haven't pushed the GHC bootstrapping stuff anywhere publicly yet, have you? <rekado_>stikonas: in some cases it’s fine to just replace the # with ' <rekado_>but others are harder for me to understand <stikonas>maybe somebody with haskell experience can help <muurkha>I think janus has haskell experience, maybe they can help <muurkha>20:42 <@rekado_> I overrode the search path and preprocessor, so I can already load some of the GHC sources, but it seems that the <muurkha> biggest obstacle is that GHC and hugs use different parsers. <muurkha>20:43 <@rekado_> so I can’t interpret all of the standard library, which the GHC sources depend on <muurkha>20:43 <@rekado_> simple example: ERROR "PrelAddr.lhs" (line 37): Syntax error in input (unexpected symbol "#") <muurkha>20:43 <@rekado_> that’s: data Addr = A# Addr# Ideriving (Eq, Ord) <muurkha>20:44 <@rekado_> IIRC in GHC that is for expressing boxed values(?) <muurkha>20:48 <@rekado_> stikonas: in some cases it’s fine to just replace the # with ' <muurkha>20:48 <@rekado_> I’ve done this where I could <muurkha>20:49 <@rekado_> but others are harder for me to understand <muurkha>(hoping that flood isn't too annoying) <janus>i don't know the details of GHC.Prim but i think it is important to note that the extension doesn't involve the runtime at all, it is just about parsing <janus>if it never had any special meaning i suppose it would be sufficient to just replace it with a different character as you have done <janus>i guess MagicHash was invented after the fact since those docs talk about 6.8 and you're working with version 5 or 6