On Wed, 11 Mar 2020 at 16:46, Paul Smith <p...@mad-scientist.net> wrote:
>
> On Wed, 2020-03-11 at 14:17 +0000, Jonathan Wakely wrote:
> > On Mon, 9 Mar 2020 at 21:56, Paul Smith wrote:
> > > The tricky bit is that although both the host and target are always
> > > x86_64/i686 GNU/Linux systems, I need the generated compiler to run on
> > > much older systems than the one I build it on.
> >
> > I suggest using containers for this. Once you've got a working
> > Dockerfile it makes life much easier in my experience.
> >
> > The podman and buildah utilities are great alternatives to docker itself.
> >
> > By building in a container using something like "FROM centos:6" you
> > know you're using those packages, not trying to convince GCC to use a
> > cobbled-together sysroot based on old RPMs.
>
> That's a good idea, certainly for building the compiler: it would save me
> having to build the initial compiler ("step 1" in Joseph's email): I can
> skip that step and just build the target compiler in a container.
>
> Unfortunately currently I target RHEL/CentOS 6.5 and there's no official
> docker image for that, but that's not a major problem.
>
> However I don't think, at least for now, I can switch to having developers
> build in a docker container. Getting that integrated with all the
> tooling/IDE environments everyone uses, etc. will be a lot of change.
> Since I want to use a much newer version of GCC than was provided in these
> older releases, a docker image won't save me having to build the compiler
> anyway; it would only change the way the compiler is distributed and used
> (inside a docker image/container vs. stand-alone with a sysroot).
My thinking was to build GCC inside the container, then package up the
results and install that on your dev machines (outside a container).
But actually that won't work because you'd also need to package the
glibc from the container, and at that point you're basically back to
using a sysroot.
