This is the mail archive of the
mailing list for the GCC project.
Re: Help about how to bootstrap gcc with local version glibc other than system one
- From: Jeff Law <law at redhat dot com>
- To: "Bin.Cheng" <amker dot cheng at gmail dot com>
- Cc: Andreas Schwab <schwab at linux-m68k dot org>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 22 Feb 2016 12:15:49 -0700
- Subject: Re: Help about how to bootstrap gcc with local version glibc other than system one
- Authentication-results: sourceware.org; auth=none
- References: <CAHFci2-MGvGREn85cu91U_KT0bqsgMuCWsfON42u5ENJaiaH4w at mail dot gmail dot com> <87egcwxpzi dot fsf at linux-m68k dot org> <CAHFci2_ZLQeZUqDYknkL7Gey7vxy6asDvn=E+v3Fu58V1_CaYQ at mail dot gmail dot com> <56AFB5F2 dot 10007 at redhat dot com> <CAHFci2_k05NxUoVsXhMpdQ7TDDq_f=zEEe_6NZa7YrubU2mibw at mail dot gmail dot com>
On 02/22/2016 11:52 AM, Bin.Cheng wrote:
If there's a fundamental incompatibility, then you have to bootstrap,
similar to bootstrapping a new architecture. That's rarely the case though.
I still don't quite follow this method. If I pop up chroot
environment with new glibc, it's still possible that the new glibc
isn't compatible with the default gcc in chroot. Won't this a
chicken-egg problem because we want to build our gcc against new glibc
in the first place?
Most of the time it's sufficient to use mock or similar tools in this
manner to build a new glibc or new gcc. You can then repeat using the
just built glibc or gcc to catch any secondary effects.