https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #25 from Stas Sergeev <stsp at users dot sourceforge.net> --- (In reply to jos...@codesourcery.com from comment #24) > > But isn't there always a possibility to add > > one more stage? Say, in the example above where > > at stage1 we only have a static-only compiler, > > we could add stage2 and stage3. stage2 is a fully-featured > > compiler to build stage3. I think this approach > > will always work, just use N+1 stages. > > It's desirable to reduce the number of stages, not increase it. I think it depends. :) So if someone wants to increase the amount of stages, why not to support also that, together with the approaches you propose. To me, its all about flexibility. > (Bootstrapping such a GNU/Linux toolchain used to take three stages, which > was successfully reduced to two by fixing glibc to build with the > first-stage GCC.) Reduced amount of stages is also good to support. :) Why not to implement both ways? > The --with-build-sysroot option gives the location of a directory that > uses the sysroot layout, which is not the same as that of a non-sysroot > $exec_prefix/$target - unless your non-sysroot layout does not use /usr. > > If you set up the toolchain so that it thinks /include rather than > /usr/include is the native system header directory, then you can use > --with-sysroot and --with-build-sysroot without any temporary usr -> . > symlinks. Ah, I am starting to understand. So basically you mean something like this: --with-sysroot=$prefix/$target --with-build-sysroot=$DESTDIR$prefix/$target --with-prefix=/ This way we simulate the cross-layout and also are changing the build pathes of headers and libs at once. And if we use the default prefix, /usr, then we'd also need to symlink everything back to $sysroot/ because, while buildable even w/o the symlinks, we'll get the wrong target layout, right? In which case we can add the symlinks after the build is completed, correct? > Those -isystem paths are the *non-sysroot* kind of paths for headers > for a cross compiler. So do you mean that on a sysroot build those -isystem will look much differently? How exactly? Or will they look similar but alterable with --with-build-sysroot? Knowing how -isystem will behave in a sysroot case is the last piece of the puzzle for me concerning your suggested solution. So your suggestion is to have some option like --with-build-time-prefix, which can be set to $DESTDIR$prefix, right? In this case the compiler will replace $exec_prefix/$target with $build_time_prefix/$target during build, right? But the question is still, why not to support both ways, if adding an extra stage is also the legal and simple way of getting the work done.
