| *** tristan has joined #buildstream | 06:57 | |
| *** jonathanmaw has joined #buildstream | 07:43 | |
| *** ChanServ sets mode: +o tristan | 08:12 | |
| *** tristan has quit IRC | 08:16 | |
| *** tristan has joined #buildstream | 08:56 | |
| jonathanmaw | morning tristan, I'm having trouble when using the debian ostree and debian packages, mostly it seems to be because they overlap with the buildstream elements in unfortunate ways | 09:01 |
|---|---|---|
| jonathanmaw | (especially because a lot of debian stuff has selinux, and buildstream doesn't) | 09:01 |
| jonathanmaw | I think for the sake of my own sanity, I'm going to have to go back and do it all properly from source. | 09:01 |
| *** ssam2 has joined #buildstream | 09:05 | |
| tristan | buildstream does not have or not have selinux | 09:05 |
| jonathanmaw | ? | 09:06 |
| tristan | jonathanmaw, Not sure what you mean, are you trying the debian ostree base and then building *baserock* on top of that ?? | 09:06 |
| tristan | jonathanmaw, I think you only need the debian base, and the element that you want to build using debian/rules | 09:06 |
| tristan | certainly, building *baserock* on top of debian would be really, really strange | 09:07 |
| jonathanmaw | I'm doing it with buildstream-tests. some elements were built with core and have brought in dependencies | 09:08 |
| tristan | buildstream-tests has multiple branches, the 'build-gnome' branch is a baserock GNOME system | 09:08 |
| jonathanmaw | tristan: that's the one | 09:08 |
| tristan | jonathanmaw, yeah, that sounds awful, dont do that | 09:08 |
| tristan | jonathanmaw, start with: https://gitlab.com/BuildStream/gnome-modulesets-base | 09:09 |
| tristan | And depend on "base.bst" | 09:09 |
| jonathanmaw | ok | 09:10 |
| tristan | jonathanmaw, in other words: The success criteria of being able to build a module with debian/rules is not that "You must be able to build a system that has all of the deps of dpkg-buildpackage by hand" | 09:11 |
| tristan | A runtime with those utilities installed in some way is just a prerequisite of the build element actually working, anyway | 09:11 |
| tristan | jonathanmaw, if that does not work out of the box (i.e. if that runtime does not automatically have those tools), then it's fairly easy to generate one on your host | 09:12 |
| tristan | By cloning https://gitlab.com/BuildStream/debootstrap-ostree/, and modifying https://gitlab.com/BuildStream/debootstrap-ostree/blob/master/data/multistrap.conf.in | 09:13 |
| * ssam2 finds https://wiki.gnome.org/Projects/BuildStream/Roadmap/CrossBuilding | 09:36 | |
| tristan | Right, what I'm thinking is _anyway_ as far as bst files which define a toolchain bootstrap go | 09:36 |
| tristan | You can always assume host compatible machine architecture | 09:36 |
| tristan | But not target compatible | 09:36 |
| *** jonathanmaw has quit IRC | 09:37 | |
| tristan | So whatever we have in gnu-toolchain, as a first step, has to first ensure that no code that has been built, will be run | 09:37 |
| *** jonathanmaw has joined #buildstream | 09:37 | |
| ssam2 | it maybe that we can only built up to stage2 in that case | 09:37 |
| ssam2 | but stage2 should be enough to produce a sysroot that runs on $target (or a virtualized equivalent) and can build stuff | 09:38 |
| tristan | Eventually, in some shiny bright crazy future, it should be possible to cross compile from mips host -> arm target... all of that on a real Intel host | 09:38 |
| ssam2 | apart from needing a kernel, which is pretty easy to automate if you're using virtualization, and pretty manual if you're using a random devboard | 09:38 |
| tristan | Right, there are the kernel concerns too indeed | 09:39 |
| tristan | Hmm | 09:39 |
| ssam2 | but they're a pain anyway as they are often sideloaded on real hardware | 09:39 |
| ssam2 | well and in VMs | 09:39 |
| tristan | Well, I suppose that something we have to consider is that bsp projects should also be made to cross compile | 09:39 |
| ssam2 | this is actually much easier with BuildStream than it was with Baserock tools I think, because BuildStream makes it easier to build a couple of artifacts explicitly and output them in a useful format | 09:40 |
| ssam2 | if the tool can cross build a toolchain and a kernel, for the purposes of my current project that'll be enough and the rest could be a wrapper script | 09:40 |
| tristan | So eventually we'll want a VM sandbox which has a requirement of a target arch runtime | 09:41 |
| tristan | But lets not talk about that until much later :) | 09:41 |
| ssam2 | yeah :-) | 09:41 |
| ssam2 | I can see how it would slot in place though | 09:42 |
| tristan | ssam2, from buildstream though, you will first want host/target arches to be defined, since we dont have that | 09:42 |
| ssam2 | makes sense, yeah | 09:42 |
| tristan | So you might want to first patch buildstream for that; and that will touch several areas | 09:42 |
| tristan | In the frontend / Context object, you'll want options for --host --target | 09:43 |
| tristan | And we'll probably also want host/target arch conditionals, instead of just "arch" conditionals | 09:43 |
| ssam2 | ok | 09:44 |
| tristan | ssam2, note that the conditionals are part of the format proper, so this might take a bit of thought | 09:44 |
| ssam2 | right | 09:44 |
| ssam2 | actually I think I need a bit more than what I said above | 09:44 |
| tristan | Currently we make use of "arch" to do some different things based on arch | 09:44 |
| ssam2 | building a stage2 cross compiler that runs on $host isn't enough | 09:44 |
| tristan | And we assume that everything is a native build | 09:44 |
| ssam2 | I then need a stage3 built on $host to run on $target | 09:45 |
| tristan | ssam2, right, you need a canadian cross | 09:45 |
| ssam2 | yeah | 09:45 |
| tristan | ssam2, I actually really, really think this would all benefit from your reviewing my aboriginal work | 09:45 |
| tristan | Because that one "works", with the same little bash script used with different HOST/TARGET combinations | 09:46 |
| ssam2 | the YBD changes, you mean? | 09:46 |
| *** xrt has joined #buildstream | 09:46 | |
| tristan | Nope | 09:46 |
| tristan | ssam2, https://github.com/gtristan/aboriginal | 09:47 |
| tristan | ssam2, that is basically a fork of aboriginal which uses a modern toolchain | 09:47 |
| ssam2 | yes | 09:47 |
| tristan | See for example: https://github.com/gtristan/aboriginal/blob/master/sources/sections/gcc.sh | 09:47 |
| tristan | As I recall, we build gcc once without libstdc++ | 09:48 |
| tristan | Then we build libc with the new gcc | 09:48 |
| tristan | Then we build libstdc++ from gcc against the new libc | 09:49 |
| *** xrt has quit IRC | 09:49 | |
| tristan | https://github.com/gtristan/aboriginal/blob/master/build.sh is the main flow of it | 09:50 |
| tristan | once stage2 is done, we have all cross tools for host arch | 09:50 |
| tristan | and then we do https://github.com/gtristan/aboriginal/blob/master/native-compiler.sh | 09:50 |
| tristan | which is cross building native binutils, libc, gcc | 09:51 |
| ssam2 | sure. So I guess the puzzle is how to implement native-compiler.sh in the context of BuildStream | 09:51 |
| tristan | ssam2, it's not that crazy; but what I would do it use that build as a reference, first for the general flow of it | 09:52 |
| tristan | And then again when things break for some reason, there are probably some tricks in there that help | 09:53 |
| tristan | ssam2, in any case, always assume there is a host arch compiler built in / | 09:53 |
| tristan | So stage1 actually becomes something like: https://github.com/gtristan/aboriginal/blob/master/simple-cross-compiler.sh | 09:53 |
| ssam2 | i was hoping to be able to have a shared gnu-toolchain stack that can be used for both cross bootstrap and normal builds, do you think that's feasible ? | 09:54 |
| tristan | first you build a cross compiler, then you use that cross compiler to build a native compiler, taking care of that build-gcc-twice thing | 09:55 |
| tristan | ssam2, Yes certainly | 09:55 |
| ssam2 | great | 09:55 |
| tristan | ssam2, the trick to that is pretty simple actually | 09:55 |
| tristan | ssam2, you just make sure you use a different host triple | 09:55 |
| tristan | So I think basically you get around it by always calling your cross compiler ${arch}-unknown-${abi} | 09:56 |
| tristan | And your native toolchain is ${arch}-linux-${abi} | 09:56 |
| tristan | the unknown vs linux makes sure all those toochain builds go through the same steps | 09:57 |
| tristan | ssam2, so yeah the one thing I'm not entirely sure of... is what to do with the existing 'arch' conditionals | 09:58 |
| ssam2 | in a backwards compatibility sense? | 09:58 |
| tristan | sort of | 09:58 |
| tristan | I mean, what do they mean, host ? or target ? | 09:59 |
| tristan | I guess an "arch" conditional is target ? | 09:59 |
| tristan | and makes the implicit assumption that host = target ? | 09:59 |
| tristan | Right now we use it for, selecting which binary runtime to import | 09:59 |
| tristan | But will also end up using it to pass special flags to some builds | 10:00 |
| tristan | ssam2, I leave that question for you to reason about :) | 10:00 |
| tristan | I think that essentially, we keep --arch... and we add --host-arch and --target-arch... everything that currently only cares about --arch, continues to do so | 10:01 |
| tristan | Only the low level cross compiling things care about --host / --target | 10:01 |
| ssam2 | but for stage 3 we also have to think about --build perhaps | 10:01 |
| ssam2 | i'm not sure this is the whole picture | 10:01 |
| ssam2 | https://etherpad.gnome.org/p/SnvGnQuCmP | 10:01 |
| ssam2 | i've tried to write out a native vs a cross bootstrap | 10:02 |
| tristan | So what is stage3 exactly ? | 10:02 |
| tristan | in your definition of the day ? | 10:02 |
| ssam2 | the elements in gnu-toolchain/ which don't have stage1 or stage2 prefixed to their names | 10:02 |
| tristan | ssam2, I dont think those exist | 10:03 |
| tristan | they have to go away | 10:03 |
| tristan | or be a part of stage2, rather | 10:03 |
| tristan | quoting myself from beginning of conversation: | 10:04 |
| tristan | <tristan> So whatever we have in gnu-toolchain, as a first step, has to first ensure that no code that has been built, will be run | 10:04 |
| tristan | ssam2, that means that basically, the output of a base runtime has to ensure that all the native stuff was built with the cross stuff | 10:04 |
| ssam2 | I agree on that | 10:04 |
| ssam2 | ok, maybe stage1 is the thing that's confusing matters, it doesn't need to be there | 10:05 |
| ssam2 | (except because of GCC build weirdness) | 10:05 |
| tristan | Thats sort of why I would prefer you try the aboriginal flow | 10:05 |
| tristan | it's much more straight to the point | 10:05 |
| tristan | you might just even try building it once | 10:05 |
| tristan | And observe the flow | 10:06 |
| tristan | ssam2, Note that the 'host-tools' beginning stage is throwaway, we dont need that because of deterministic host inputs | 10:06 |
| ssam2 | does https://etherpad.gnome.org/p/SnvGnQuCmP make more sense? | 10:07 |
| ssam2 | I don't think it correspond to the current gnu-toolchain stratum, that's probably where i've been getting confused | 10:08 |
| ssam2 | but as long as there's some way in buildstream to work out that $target_arch needs to mean armv8b64-unknown-linux-gnu in some places and armv8b64-baserock-linux-gnu in others, it seems workable within BuildStream | 10:08 |
| tristan | No it does not work exactly the same as the current baserock things | 10:10 |
| tristan | ssam2, look at configure_gcc() function, and how it's invoked in https://github.com/gtristan/aboriginal/blob/master/sources/sections/gcc.sh | 10:11 |
| tristan | Note that we make use of --program-prefix | 10:11 |
| ssam2 | my confusion isn't over how to build a cross compiler, I did this exact same work 5 years ago ... it's just how to fit into buildsdtream | 10:11 |
| ssam2 | but I think I get it now | 10:11 |
| tristan | and in the canadian-cross builds, we do alot of env assignments before configure, like CC_FOR_TARGET=${CC_PREFIX}cc | 10:12 |
| tristan | where CC_PREFIX is actually the --program-prefix we gave in the stage1 build | 10:12 |
| tristan | which is like "${arch}-" | 10:12 |
| tristan | ssam2, yeah - I understand, I broke my brain cells quite a bit wrapping my head around this last year; the thing is I really think landley's builds are done very well compared to ours; and they get "every host/every target" done with the same build scripts | 10:14 |
| tristan | That is what we want | 10:14 |
| tristan | You can go pretty far down the rabbit hole | 10:14 |
| ssam2 | we should really just spend a year rewriting the GCC build system ;-) but that's more than just a rabbit hole | 10:16 |
| ssam2 | probably more than a year as well | 10:16 |
| tristan | Eh | 10:16 |
| tristan | I have little faith | 10:16 |
| tristan | Better put that effort in clang or smth else | 10:16 |
| ssam2 | well, perhaps. there's less C++ in gcc though :-) | 10:17 |
| tristan | gcc has hard coded paths depending on what C library *it* was compiled with | 10:17 |
| ssam2 | yeah gcc has all sorts of mess | 10:17 |
| tristan | So you can NOT build a program against a libc that GCC was not compiled against | 10:17 |
| tristan | When I asked about this, I was told: NO. | 10:18 |
| tristan | almost there, I have totally lobotomized the sandbox API to allow some things and I think I've put things in the right places | 11:41 |
| tristan | Anyway now the sandbox directories are split up a bit, with root/, user/ and scratch/ subdirs | 11:43 |
| tristan | Elements stage artifacts into root, but anything else custom (sources) into user/ | 11:43 |
| tristan | And can define mount points for things they add in user/ | 11:43 |
| tristan | This leaves the sandbox implementation(s) free to do things a bit differently, like take care of adding a fuse layer (mounted via scratch/) on the /, in the case that it is not read-only, to provide the copy-on-write hardlink thing | 11:44 |
| tristan | anyway all the elements seem to be working now with this adjustment... just have to plugin that fuze layer | 11:45 |
| tristan | *fuse ... and then I can undo my workaround for artifact caches and start using user mode checkouts again | 11:46 |
| *** tristan has quit IRC | 12:33 | |
| *** jonathanmaw has quit IRC | 15:24 | |
| *** jude has quit IRC | 16:45 | |
| *** tiagogomes has quit IRC | 17:15 | |
| *** ssam2 has quit IRC | 17:15 | |
| *** violeta has quit IRC | 17:15 | |
| *** violeta has joined #buildstream | 20:22 | |
| *** violeta has quit IRC | 20:27 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!