<stikonas>argh, something is messed up on 2nd pass <stikonas>or maybe with ${MES} --no-auto-compile -e main ${bindir}/mescc.scm -- -nostdlib -o /after/bin/mes-new -L . -lc crt1.o gc.o hash.o lib.o math.o mes.o module.o posix.o reader.o string.o struct.o vector.o -lc <stikonas>but need to rerun the whole thing to see error message... <stikonas>probably missed some file in kaem script... <fossy>Does it have all of the required .os there from configure-lib.sh <stikonas>well, I found some missing ones... just started rerun <stikonas>I was comparing to actual non-live run too... <stikonas>by the way, what is tcc.a in mes? C library for tcc <stikonas>unhandled exception: error: (("mescc: file not found: \"x86-mes/libc.a\"")) <stikonas>${MES} --no-auto-compile -e main ${bindir}/mescc.scm -- -nostdlib -o /after/bin/mes-new -L . -lc crt1.o builtins.o cc.o core.o display.o eval-apply.o gc.o hash.o lib.o math.o mes.o module.o posix.o reader.o s\ <stikonas>tack.o string.o struct.o symbol.o vector.o -lc <fossy>I *think* you should cp libc.a into lib/x86-mes <stikonas>I guess that's logical thing to do given this message <stikonas>it's just that last time logical thing failed :D <OriansJ>siraben: your pull request has been merged (sorry for the delay) <OriansJ>thank you fossy and stikonas for helping to solidify the stage0-mescc bridge <stikonas>OriansJ: well, the thing is it won't be as easy to go beyond mescc there... (because we can't run gash) <OriansJ>stikonas: well I guess we need to solve the gash bootstrap problem then <stikonas>or just write a few more kaem scripts to get bash <stikonas>which is more boring but might be quicker <OriansJ>well kaem absolutely works thanks to fossy <stikonas>and it's not as big gap to bridge as M2-Planet -> mescc <OriansJ>and we can always extend it if things are required. <stikonas>I wonder if blynn-compiler will eventually solve ghc bootstrap problem... <stikonas>(but I myself know absolutely 0 haskell...) <malina>there is very little I hate more than ghc and haskell packages <malina>maybe python, and that's about it <OriansJ>stikonas: with enough love and desire to do so; I believe absolutely. <OriansJ>malina: then we will make sure to never ask you to work on those packages. <vagrantc>i didn't think npm was something that was maintained ... it kind of sprawls <malina>who are 'we' , which 'packages' and for which 'package' system? <malina>I was thinking you would maybe join my system, in which case I _could_ indeed do _more_ work. generally. <malina>but ye, ghc what a bunch of <highly redacted sequence of double redacted> <OriansJ>malina: we as the people on this channel. Which packages, those that you said you hated as a maintainer. for all packages systems for which we may be forced to maintain packages. <OriansJ>vagrantc: there is a huge difference between maintaince and curation. NPM is will maintained but it sure as shit isn't curated. <malina>I just build it, and yes, I recall some 'ugh' with it, like obviously the "ugh" stuff is about 8-10 sets I'd say, but still, ghc/haskell is one of the most inadequate "systems" one comes across. <OriansJ>malina: well all systems come with trade-offs. I wonder what was gained by those choices <malina>and yes, everything is oppurtunity cost <malina>whose choices OriansJ ? ghc / haskell package devs? <xentrac>what kinds of problems do you have with ghc and hackage? <malina>npm? although I used to adore mosml, but use njsml the few times I do here, I'm sure haskell itself is ok, but just the ecosystem of theirs is horrid to integrate and deal with from a more "traditional linux" set of tools and environment <malina>well, I rate usually such 'system blocks' an absolute nuisance if they are _horrible_ in the "bootstrapping phase", whether it be early stage or 'upgrade' <malina>rust , D, java, ada, ghc, python,*packages etc all have their pros and cons <malina>it takes f()&(*^&*%*& "years (exaggeration) to sort out ghc packages and all their deps when upgrading, even if one wants some nomimal small subset <OriansJ>but probably something that makes the Developer lives easier. <malina>it's the kinda level, I could pay to kill people.. that's how, horrid. I haven't lluckily bothered with it in eons, and I don't intend to touch upon it for a good many weeks yet, ask me again then, and I will happily give you a VERY detailed list/log over just how bad it will become, <xentrac>what's the time-consuming aspect of ghc packages? <malina>yes, I am talking about the various packages internal 'eco-system' <malina>I didn't say haskell itself has to be a bad language at all <xentrac>like, are the links to the web sites broken, so you can't download the source code? <malina>I am strictly talking about the horrible packaging they came up with. <malina>the inefficiency , measured in time, <malina>the kinda stuff one could self-aphyxiate over if one was a minor god <malina>I'll happily recall this and revisit this for you next time I deal withit <malina>I usually avoid it as much as possible so it's only maybe once eevry 7 months or so, so it might be a while <malina>but I have no problems giving you a accurate discourse then. <malina>it's the endless cyclic dependencies i mean <xentrac>so far the only useful advice I've been able to extract from this is "don't make packages that take a lot of time to upgrade" <malina>the bootstrapping.. it's hopeless <OriansJ>malina: never hopeless just sometimes a pain <OriansJ>There are very very good reasons why most users use distros instead of Linux from Scratch <malina>I don't know, even if long packages as in long time per one unit, are tedious, I will far more prefer one long hit , than the perennially small ghc ones with the _cyclic_ BOOM. I mean, if that is the best haskell came up with as a package manager.. then no wonder I don't explore further that language, and stick to sml, for my tiny needs (usually very small subsets of some problem). If people here are vested in ghc fine, it won't change the <stikonas>well, Linux from Scratch is very non-automated <malina>sure I started off on lfs, but I already had all my designs, so I am a distro, it's just that I am alone. <stikonas>probably our automated bootstrap to usable system will be quicker than setting up lfs <malina>that is the issue, not so much anythign else. I solve most problems and develop good policies for avoiding problems which shouldn't be there. But alone, means feature elist goes to hell, (bug list isn't really very problematic).. it's losing all the features :( to time <malina>watching all the trains constantly leaving the peron, andbeing left with the janitor broom stick <malina>lfs is a very important source of knowledge; I would find it absoultely ridiculous if a channel working with #bootstrapping , wouldn't understand that. <malina>I , as the majority of distros, actually used lfs as the guide to building their system <malina>guix being definitely one of the exceptions <stikonas>many distros are older than lfs though... <malina>I can imagine. but ye, still not sure if I should download it, or maybe try to work with this directly in my thing. but sigh. <OriansJ>well most successful distros figured out that compromise and cooperation always farther than individual greatness. <malina>but even when they were rebasing, many a time one can see newer/younger maintainers of said, old distros would still find advice and resources in lfs <malina>what ar eyou , bashing LFS for some reason in something like #bootstrappable? I am confused. <malina>sure, compromise, cooperating, I am not at all bad at it <OriansJ>malina: how long have you been publicly sharing your distro work? <malina>4 years, I have given some people some test measurs <malina>but most of the time, when I get a "I'll help" it sizzles out once they realise it's hmm a big project to do, OR of course, it's mainly "bootstrapping/lfs/somoething" chans, so I think finding "contributors", "testers", are harder than finding "devs who want to use their ideas in this distro work" <OriansJ>well distros like Debian and Guix make their work public for the world to see. <malina>unfortunately, I am looking mainly for D language devs, still no ambition in irc, C? sure, but they are doing their own thing, do get bash/awk gurus but that's not what I need nor want as I am trying to actually consolidate a lot of that into D say. <malina>I did think , it would be easier to search out a 'team' several years ago, I realise.. no, not really. I see why, I suppose, but I did feel irc was so less than what I thought it would be. the people. it's just "I want free stuff" and "bla bla" <OriansJ>So you want D developers to contribute to your distro that is private. <malina>I speak with several over years you know <malina>they sit and do their lil projects and many of them are going nowhere, so I hoped maybe some of them would want to be part of a more directed larger thing. <OriansJ>malina: everyone here is getting free help from everyone else's work <malina>Anyway, I think I know what you wish to highlight; sure, I am not really lamenting that I am not offering publically. <malina>yes, but therein comes the philosophy of equal reciprocation. In terms of honour and so on. <OriansJ>5 people all put in 20% and all get 100% of what they wanted. <malina>honour just a small subset of course. <malina>I don't mean simple monetisation here but feel free to add it to the list <OriansJ>malina: no one here (except maybe yt) gets paid to contribute <malina>but someone mentioned npm.. I saw just soe days ago, the classic viral , evil , soulless, egotistical person who only wants, and then when no longer gets, is happy to take from the giver <malina>and destroy it and not onlythat, even finds it evil for the good person to share. LOL <OriansJ>the rest just get a bootstrapped Guix <malina>gnu/gpl people don't have much clue about that part anyway, so forget that bit <OriansJ>I believe that yt likes to be paid money from his job. <malina>but a npm library , some russian , young chap, spends years creating some quality lib , "oh fanf*ckingtastic" they say. <malina>well good, then he understands reciprocity above average, swell. <malina>this young russian, I saw, was driving home some night and a drunk young couple , laughing , stubmle across the street away from the zebr crossing yaddi ya <malina>he crashe din them of course, the lass dies <malina>mum of course will just blame him even if he was sober, didn't do anyting 'wrong' but the drunk obviiously did but yu know mums, erratic beyond belief, never make them world leaders, let me tell ya! <OriansJ>xentrac: no clue but I didn't want to deal with gender pronouns in this discussion which already is well off the rails <malina>anyway, he goes to jail for aw hile because he can't pay the costs to the mum, etc <malina>and the nice "freeloading' people go FUCK YOU YOU SHIT , WELL WE WILL TAKE YOUR WORK THEN AND FORK IT AND DO WHAT WE WANT WITH IT <malina>thankfully a lot of popele aren't evil like that, but many are, way too many <malina>often calling themselves "gnu warriors" <malina>well, no worries, you asked. If you try to starta convo, I expect one could discuss anecdote, but no probs. <OriansJ>malina: what do you think the GPL is for? Protecting User freedom. <malina>to some degree or rather, in a flawed way <OriansJ>malina: no, in exactly the way it specifies <malina>but that's ok, it has at least "noble intent", in my world, that also matters. <OriansJ>People have work to discuss and we are not going to distract them any further. <stikonas[m]>Bed time... Will finish kaem script for mes tomorrow... <stikonas[m]>Was getting some error about __stdin and it will need further look <siraben>OriansJ: thanks, don't apologize, the fault is mine for leaving it unmerged. <OriansJ>xentrac: to your previous question it never occured to me that yt's gender was a bit of metadata that mattered as their code is good and they seem like a hard working person. <xentrac>oh, I was just worried they might get grouchy if you were misgendering them; sometimes people do that <OriansJ>xentrac: good book. but when I think of yt I think The country code for Mayotte <OriansJ>and the beautiful beaches; that goes well with the flowing code style yt has. <xentrac>now I wonder if I've stirred up trouble where I was intending to forestall it <OriansJ>xentrac: well I like to think of it this way. On IRC no one knows if we are dogs, parrots, cats or humans. <OriansJ>But treating people respect and acceptance is always in good form. <OriansJ>but if I offended yt, they are more than free to call me a dumbass and rip me a new asshole for missing something i wasn't looking for. <siraben>stikonas: GHC bootstrap problem seems difficult, the best option might be to identify the oldest GHC written C then bootstrap there <siraben>Though I wonder if anyone's actually made a bootstrap like that <fossy>I have never read a stranger backlog than I just did <fossy>I just use they/them if I am unsure <fossy>OriansJ: fwiw I believe that yt is not being paid but rather has some agreement with their employment that they must ask before contributing code to anything, common in many orgs <malina>well, yt , she or he is logged in via the #1 uni in the world. If you go to the city, and live or just go out really, all you'll meet are people from oxford, durham, warwick, lse, imperial college, you name it.. almost never cambridge.. why? Becuase usually they are that smart I suspect, they always get recruited to intelligence. <malina>One would think that was vastly exaggerated but I swear I can meet 50 oxforders to a cambridger. <malina>because you don't know the country, else it would be fairly on-topic. <malina>don't worry, as always, education nor intelligence is irc's strength, but rather "oh let me call a pot a pit and a cat a hat". :) Not that I care very much. anyway, ni ni. ***ChanServ sets mode: +o rekado
<OriansJ>malina: I don't care where people come from. Be it Russia, China or Hell Michigan. I don't care what organization that they work for. Be it CIA, NSA, KGB (FSB or whatever the hell they are calling themselves these days), ISIS or the damn British Postal Service. I only care that the work is trivial to audit and easily verifiable as correct and nonmalicious. <rain1>I think i was with you til ISIS :P <stikonas>in any case it's wrong to say that all Cambridge people end up in intelligence... I have not heard of any at all, so if there are any, it must be a small number... <rain1>I did get an email from ghcq asking me to apply when I was studying at cambridge <stikonas>well, I am not brittish, so I guess that disqualified me from their email... <stikonas>but even british people that I know didn't end up in ghcq, etc... <rain1>i was there about 2012-2013, did part III <stikonas>oh, so we did Part III in the same year! <rain1>did you have ben green at all? <rain1>I met some of the physics people there were very friendly <siraben>Not at cambridge, but I'm currently studying maths and CS at a US university, heh <stikonas>I might have been to some ben green public talk <rain1>that's such a coincidence stikonas ! <siraben>Took abstract algebra last semester, was great <stikonas>later I want to do PhD in Edinburgh but now back in Cambridge working as programmer <siraben>relatedly in CS, I also like programming language and type theory <rain1>yes that stuff is very exciting <siraben>blynn-compiler could be a good way to see those concepts applied, naturally <rain1>it's interesting to think about how machin checked proofs interacts with the whole bootstrapping thing <siraben>it's like a proof by construction right? making successively larger and larger compilers <siraben>Great, I'll use this as an alternative to the hello world test case in the CI <rain1> https://bpa.st/A4CA this is a problem that i'm having with mescc building tinycc: mescc has built and works but for some reason it's failing on the conftest program <rain1>maybe i should be doing something other than ./configure though <stikonas>rain1: don't you need to run bootstrap? in tinycc <stikonas>although, I'm still working on mes in live environment... <rain1>hm bootstrap.sh runs and exits with code 0, prints nothing out <gforce_de1977>rain1: can you add an 'set -x' ontop, and let 'bootstrap.sh' run again? <gforce_de1977>rain1: i'am not sure if we are talking about the same file 8-) <gforce_de1977>rain1: it starts with '#! /bin/sh' (with a space!) - do you have /bin/sh around? *yt_ reads back today's log and has a good chuckle <yt_>xentrac: thanks for getting the reference! Y.T. is female, but I'm not. My (real) first name is most commonly a girl's name where I'm from, so I felt using yt was quite apt :-) <yt_>OriansJ: I (unfortunately) don't get paid to contribute to this project (I do so in my own time), but my employer likes to know what I contribute in my spare time, especially where there might be conflicts or similarities with the work I do as a day job. <gforce_de1977>yt_: are there conflicts or in other words: what is your daytimejob? <yt_>gforce_de1977: in my day job I do performance work on LLVM, primarily AArch64 <janneke>rain1: if you look at the guile recipe, you can see that you need to remove volatile from conftest.c: <janneke>(substitute* "conftest.c" (("volatile") "")) <yt_>gforce_de1977: Arm (but I do not speak for my employer, opnions are my own, etc etc) <janneke>either that, or generate a config.h by hand <gforce_de1977>janneke: for my upcoming talk in our hackerspace, i'am searching for a good way to explain blood-elf-0 and blood-elf, the same for hex2-0 and hex2. for the latter i just use hex2 and hex3 and 'hexX' is OK, but blood-elf? <janneke>hmm, come to think of it, if nyacc parses it correctly, then having mescc filter 'volatile' from the parse tree would be trivial (and may be helpful) <rain1>maybe when I build mes I need to build a 64 bit version? I feel like it did 32 bit <janneke>rain1: are you building an unpatched tcc? <janneke>that won't work, not with mescc at the moment <rain1>i did not git checkout remotes/origin/mes-0.23 <stikonas>and I was wondering why it just work for me... <janneke>mescc builds the patched tcc initially without -D HAVE_LONG_LONG, without -D HAVE_FLOAT (and some more) <janneke>rain1: while you are testing to "get it going", you may use use Guile as a mescc driver, i.e., MES=guile V=2 ./bootstrap.sh <janneke>gforce_de1977: i don't fully get your question, but maybe better ask OriansJ anyway for stage0 terminology and semantics <janneke>gforce_de1977: i guess you know that blood-elfX adds dwarf debug symbols <gforce_de1977>janneke: i know, it's more about the word 'blood-elf' - why is that? i dont get the joke, will ask OriansJ <janneke>dwarf/elf (but i have forgotten if there's deeper `blood' pun/reference) <gforce_de1977>OriansJ: for my upcoming talk in our hackerspace, i'am searching for a good way to explain the 'blood-elf' - is there an explanation, how you found this word? where is it coming from? <janneke>stage3/blood-elf_x86.c:486: file_print("blood-elf 0.1\n(Basically Launches Odd Object Dump ExecutabLe Files\n", stdout); <gforce_de1977>OriansJ: blood-elf = Basically Launches Odd Object Dump ExecutabLe Files <rain1>this is great it is building away now <rain1>> you can build gcc with tinycc with mescc which is a little c compiler and stlib written in scheme, which can be bootstrapped off M2-Planet which is a scheme interp written in C.. that is compiled using a very basic c compiler written in assembly which can be assembled by some other tools that are intitally built using just a hex->binary translator <janneke>"M2-Planet which is a scheme interp written in C" <janneke>M2-Planet is a transpiler for the M2 language, which closely resembles a subset of C <rain1>export prefix="$PREFIX" I think this might fix it *xentrac transpiles janneke <janneke>rain1: ah yes, you have to set prefix <janneke>rain1: other than that, your summary is correct <janneke>you could add details, such as that mes is a scheme interpreter and is bootstrapped by m2-planet <rain1>so to correct this, mescc is running in mes scheme interpreter, which is compiled by M2-Planet (the C-subset) ? <janneke>or that building gcc is also not a trivial step <rain1>is this expected? for check.sh <stikonas>fossy: when you have some time, can you take another look at my changes... I made some progress, but I'm getting stuck again <gforce_de1977>rain1: dont forget to rebuild tcc with tcc, IMHO we need this <stikonas>doesn't bootstrap.sh rebuild tcc with tcc? <stikonas>just opened bootstrap.sh and I can see it does that quite a few times... <rain1>is there some theory about how many times it can be done until there is a fixed point? <rain1>i suppose you may never get a fixed point <rain1>(but in a compiler that isn't specially written to do trhat, it probably happens after 1 or 2 builds) <stikonas>but I guess it's possible to write it such that fixed point is not reached any time soon... <stikonas>or maybe it starts to cycle between a set of points <janneke>(which is also unexpected, I was expecting: PASSED: 13/256, but i may have a dirty work tree) <janneke>however, if you look at test.sh, that's using GCC_TCC, assuming there is a i686-unknown-linux-gnu-gcc available <janneke>eh, no, make that a ./i686-unknown-linux-gnu-tcc <janneke>which is built by ./build-32.sh, using a i686-unknown-linux-gnu-gcc <janneke>these checks are currently only used for/during development; it's a TODO <yt_>on the one hand, M2-Planet being a subset of C is great, cause I can write and debug most of a program with gcc and good tool support. On the other hand, the incompatiblities can bite hard sometimes: "if (!pointer)" silently "miscompiles". <yt_>made worse by what I think is a gdb bug: set a breakpoint on an "ldrsw x0, label", and it will load the literal label, *not* the word at location [label] *yt_ starts cleaning up file_print() everywhere <janneke>wouldn't want to have a vaguely similar language without this gcc/gdb fallback possibility <yt_>janneke: oh I absolutely agree with the design decision. I just dream of M2 being slightly more helpful sometimes ;-) <janneke>more debug info for m2-planet or mescc binaries would be great <yt_>jannke: m2-planet is slightly ahead of mescc in that respect, as it at least has ELF symbols <stikonas>yeah, I just had a crash in mes, and can't get backtrace :( (probably something wrong in my build script) <janneke>yt_: huh, what does m2-planet have more than mescc? <janneke>i may have missed something, mescc only has function symbols <yt_>janneke: oh maybe I've missed something in mescc? I thought it didn't generate debug ELF? <janneke>mescc has an (almost) posix command line interface; did you use -g? <janneke>iirc, OriansJ has created blood-elf for mescc, before creating m2-planet anyway, he may have had plans earlier <yt_>janneke: I think I read "-g add debug info [GDB, objdump] TODO: hex2 footer" in mescc's help message and assumed it wasn't fully functional yet <yt_>I think I briefly tried to hook it up while in the middle of my AArch64 port but didn't get it to work properly for some reason <janneke>oh, yeah that TODO looks weird to me now, at least I can't remember what that could mean <stikonas>janneke: I tried -g option but gdb doesn't seem to like those binaries <stikonas>BFD: warning: /home/andrius/repositories/bootstrap/mes/bin/mes-new has a section extending past end of file <stikonas>"0x7ffe670aaea0s": not in executable format: file format not recognized <janneke>stikonas: hmm...; works for me on guix's wip-full-source-bootstrap: <janneke>$ gdb $(./pre-inst-env guix build -e '(@@ (gnu packages commencement) mes-boot)')/bin/mes <janneke>Reading symbols from /gnu/store/dfwkand25k6nsmrk85p8hsa1yq74y314-mes-boot-0.22-305-g2ab4c5c67/bin/mes... <janneke>(No debugging symbols found in /gnu/store/dfwkand25k6nsmrk85p8hsa1yq74y314-mes-boot-0.22-305-g2ab4c5c67/bin/mes) <janneke>Starting program: /gnu/store/dfwkand25k6nsmrk85p8hsa1yq74y314-mes-boot-0.22-305-g2ab4c5c67/bin/mes <janneke>stikonas did you compile mes for 64bit? <janneke>i got a similar error to the one you showed last week, on my mes-m2 binary <stikonas>hmm, probably my kaem script... but I can't see what I'm doing differently... <stikonas>well, maybe fossy can take a look later today... <janneke>although OriansJ and myself developed the ELF headers for mes, with and without debug info together, it seems that someone decided to require another debug ELF header <janneke>iow, mes' and m2-planet's debug ELF headers have diverged, so it seems <janneke>i think that's unfortunate and iwbn to align them again <deesix>There're ELF pieces all around. There's also a compatibility change for some BSD that's not applied everywhere. <stikonas>fossy: I just got an idea which at least excludes a lot of stuff <stikonas>and I tried to run it outside live environment <stikonas>but the good news is that all libs have the same sh256sum in kaem vs mes bootstrap.sh <stikonas>so probably something is going wrong in the last steps <stikonas>mes-new is also 4 bytes smaller than mes-mescc <stikonas>so I'm trying to see what is miscompiled <fossy>the mes generated by mes-m2 is likely buggy <stikonas>because it works fine via bootstrap.sh outside live environment <stikonas>fossy: I think I finally found the difference <stikonas>I think the one that has some config.h stuff <stikonas>yep, if I replace symbol.o with the other, then it doesn't crash... <stikonas> /home/andrius/repositories/bootstrap/mes/pre-inst-env mescc -c -D HAVE_CONFIG_H=1 -I ../include -I ../include/linux/x86 -D HAVE_CONFIG_H=1 -I include -I include/linux/x86 -L lib src/symbol.c <stikonas> /home/andrius/repositories/bootstrap/mes/bin/mes --no-auto-compile -e main /home/andrius/repositories/bootstrap/mes/bin//mescc.scm -- -c -D HAVE_CONFIG_H=0 -D MES_VERSION=0.22 -I include -I include/linux/x86 src/symbol.c <stikonas>the former works but we don't have config.h <fossy>touch config.h and true again <stikonas>anyway, now I'm much close to figuring this out <stikonas>when I decided to compare object files with sha256sum :) <stikonas> /home/andrius/repositories/bootstrap/mes/bin/mes --no-auto-compile -e main /home/andrius/repositories/bootstrap/mes/bin//mescc.scm -- -c -D HAVE_CONFIG_H=0 -D MES_VERSION=\"0.22\" -I include -I include/linux/x86 src/symbol.c <stikonas>well in kaem I probably don't need to escape " <stikonas>fossy: oh, on unrelated note, after tcc we can try to get gzip working, it seems to be very easy <OriansJ>janneke: M2-Planet and blood-elf evolved the ELF headers to be more standards compliant and portable <OriansJ>So MesCC will only need to copy the new headers to be fully standards compliant <OriansJ>blood-elf-0 is just blood-elf without dwarf stubs (because we need blood-elf to generate them) <OriansJ>as blood-elf cuts the dwarf problem down to size <OriansJ>janneke: you'll also gain *BSD support with the new headers <janneke>OriansJ: thanks, i'll look into that <OriansJ>It also shrinks the debug header to reduce audit effort <janneke>oh, i added special versions for freebsd last year (actually they were contributed i think) <janneke>anyway, this helps; i'll know what to look for <janneke>i won't have much time the coming week, though <OriansJ>it is a trivial patch just replace the .hex2 elf headers with the ones inside of M2-Planet <OriansJ>which will also give you a headstart on AArch64 support too <OriansJ>gforce_de1977: I'll probably have to write up a big explaination for all of the steps for you when I get some free time to do so. <yt_>OriansJ: did the typedef change in M2-Planet break the mescc-tools-seed bootstrap? <fossy>stikonas: you need to escape quotes in kaem <stikonas>ok, I pushed the new change, but still need to test it <OriansJ>yt_: kinda but not in a hard to fix way. basically you only need to add is --bootstrap-mode to get it working again <yt_>OriansJ: ah, of course! <OriansJ>as it was to enable a more advanced FILE definition with M2libc for much better performance. <stikonas>well, if we can't escape, we can always create that config.h file... <stikonas>oh, in kaem escape eats the next character...