On Tue, Nov 13, 2018 at 4:51 PM Alexandre Oliva <ol...@adacore.com> wrote: > > On Nov 13, 2018, Richard Biener <richard.guent...@gmail.com> wrote: > > > Reworking gnattools build to always use host CC/CXX in "stage1" (or for > > crosses) > > rather than doing sth different. > > > Yeah, but gnattools is bootstrapped, right? > > No, it's not built in stage1, it's a post-bootstrap host subpackage.
Huh, indeed - it's a host_module without bootstrap ... and libada is a target_module not bootstrapped either. So we're indeed in a curious situation where we have a bootstrap of Ada requiring a host Ada but nothing of Ada is actually bootstrapped ... ;) > > For --disable-bootstrap you get binaries built with the host compiler > > throughout and that's good. > > I guess it *could* be built with the host compiler, and linked with that > runtime. Then, in order to run it, you might still need the previous > gnat rts shared libs. Just like for a non-bootstrapped compiler > front-end, yeah. Yeah, I expected that for non-bootstrap. And I somehow assumed it was bootstrapped so I'd get gnattools and gnat1 not depending on the host compiler libs. I guess we're lucky for gnat1 because it's written in C? At least I now somewhat understand why we wind up with the bootstrapped CC/CXX for the build of the stage3 host modules. > > Whereas for a bootstrapped compiler, you'd want to use what, the stage2 > compiler, that built other final host tools, to build gnattools as well? > > All doable, but not without additional complexity. I'm afraid I fail to > see the upside. > > Unfortunately we don't have a lot of other post-bootstrap host tools > linked (on native builds) with target libraries to draw parallels. I > guess we could reason about them as if they were part of the gcc/ > subdir, and this would lead down the path you suggest. I will then > point to the complications arising from using a just-built libstdc++ in > subsequent stages, and in later target builds in the same stage, and > conclude it's far from trivial, it's actually quite error-prone and > hardly glitch-free, and so it's not too hard to understand why gnat, > that had to take care of this before we even thought of bootstrapping > libstdc++, took a different path. > > Anyway... I won't take your suggestion as an objection to the proposed > patch, but I will say that I still have a lot to learn about the Ada > build machinery to be able to grasp the impact your suggestion might > have on existing uses, so, as much as I like uniformity and symmetry, > I'm not jumping right onto it ;-) ;) Richard. > > -- > Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo > Be the change, be Free! FSF Latin America board member > GNU Toolchain Engineer Free Software Evangelist > Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe
