IRC channel logs

<stikonas>ok, pushed M0_amd changes to use GAS style defines and position independent code

<oriansj>stikonas: well the ELF header uses --base-address to set where to put the binary in memory. So not setting it would result in the binary being placed at memory address zero and the first read would result in a page fault

<stikonas>and turnst out it was the last amd64 program in stage0 that had non-position independent code

<stikonas>though kaem, hex0, hex1, hex2 and catm still use old defines in comments)

<stikonas>anyway, now on amd64 --base-address can be almost arbitrary

<fossy>I haven't kept my eye on RISCV bootstrapping for a little while, but i was very glad to stumble across this today

<fossy> https://ekaitz.elenq.tech/tag/bootstrapping-gcc-in-risc-v.html

<stikonas[m]>fossy: unfortunately it's not the same GCC version that live-bootstrap was targeting

<stikonas>and converted catm_amd64 to use GAS style defines too https://github.com/oriansj/stage0-posix-amd64/blob/master/catm_AMD64.hex2

<doras>By the way, we started using the source manifest in freedesktop-sdk-binary-seed. Works great :)

<doras>Relevant BuildStream source plugin, for those interested: https://gitlab.com/freedesktop-sdk/freedesktop-sdk-binary-seed/-/blob/main/plugins/sources/live_bootstrap_manifest.py

<stikonas>doras: nice! So what are the next steps to get freedesktop-sdk from freedesktop-sdk-binary-seed?

<doras>stikonas @stikonas:libera.chat: next we need this MR merged, which fixes our Docker image publishing: https://gitlab.com/freedesktop-sdk/freedesktop-sdk-binary-seed/-/merge_requests/7

<doras>As and then we try to use the mage as the binary seed for freedesktop-sdk.

<stikonas>well, hopefully you'll also get python from live-bootstrap soon, so building freedesktop-sdk shouldn't be too hard

<stikonas>and possibly newer GCC, but that will take longer

<doras>Newer GCC would definitely make things easier

<stikonas>well, its best to wait for fossy to finish python work first

<stikonas>I think he said that it's hard to build old pythons with new gcc

<rillian>why is it `catm` and not just `cat`?

<oriansj>rillian: because the shell at that stage doesn't support pipes

<oriansj>so we need the functionality of cat $file1 $file2 ... $fileN >| $output and thus we created: catm $output $file1 $file2 ... $fileN

<oriansj>if you want catm to behave like traditional cat, one need only catm /dev/stdout $file1 $file2 ... $fileN | etc

<rillian>oh, I see, thanks. Didn't think about the argument syntax being different!

<stikonas[m]>catm is also usable to replace cp, but again order is swapped

<stikonas[m]>Or you can use it to create an empty file

<oriansj>basically, we know a good many ways to work around missing tools to get things bootstrapped. Honestly very little is actually needed to get very far on one's bootstrap chain.

<stikonas>well, random small tools are not too bad to write in M2 dialect

<stikonas>it's the larger projects like compilers that are trickier

IRC channel logs

2023-01-15.log