https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #21 from Stas Sergeev <stsp at users dot sourceforge.net> --- Hi Joseph, thanks for your assistance! (In reply to jos...@codesourcery.com from comment #20) > The only case where the newly built GCC should be overridden is the > Canadian cross case, Since today, this is no longer true. :) https://code.launchpad.net/~stsp-0/+recipe/djgpp-daily I managed to get the build working, and this build only works when possibility exist to override the in-tree tools. It works as follows: - The stage1 cross-compiler is built with --prefix=${DESTDIR}${stash_area} and installed with DESTDIR unset (it is already in the prefix). This is a non-sysroot build so it can work on host. - The stage2 compiler is built with --prefix=/usr and installed with the DESTDIR set to the build dir. As the result, this stage2 compiler can't build its libs! (libgcc, libstdc++) It can't build its libs because it is never installed into its prefix dir on host, and so I override its in-tree tools with the ones from the stage1 compiler. > Your problem as originally described was with finding non-sysroot headers. Yes, I attempted the 1-stage build back then. But why not to support the 2-stage build, as this is what I already have? It only required a tiny patch above, and since it can't be applied as-is, I can take a look into making it a separate option. What I want to point out is that there is already the use for such option, because it is already used in my build (in the form of the --with-build-time-tools hack for now, but can be extended). > A plausible approach to fixing that if you can't use sysroots is to add a > a new configure option whose purpose is to point to the build-time > non-sysroot location of headers that should be used in building target > libraries. I think I tried this already, see comment #10. I did a hack to change the header pathes. And that worked, but then there are those -B options that prevented the libs from being found during configure process. So I found the change-headers-path approach infeasible and implemented a 2-stage solution. Do you still think that the path-altering games can lead to a solution? And since I already succeeded with overriding the in-tree tools, why not to implement that route as a new configure option? It looks very simple.