[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #37 from joseph at codesourcery dot com --- On Wed, 9 Oct 2019, stsp at users dot sourceforge.net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 > > --- Comment #36 from Stas Sergeev --- > (In reply to jos...@codesourcery.com from comment #35) > > what you want. I'm familiar with many of the details through having > > written multiple such build systems myself. > > But even you do make the wrong expectations. > Most of your suggestions (which are very reasonable by > themselves) do not work or require additional tweaks. > configure reacts inadequately on them. They're essentially hints about approaches to look at - not full recipes, because that ends up in writing a whole build system. > Does --with-sysroot disable prefix, or prefix should > be set to '/' explicitly? Or to something else? A toolchain always has a prefix, as configured using --prefix=. --with-sysroot sets a sysroot path (normally under the prefix, but that isn't required). In the case where the target has an OS with a root filesystem that can have libraries and headers installed for native compilation, the --with-sysroot directory is expected to be laid out like the relevant parts of the target's root filesystem. > If I naively do > --with-build-sysroot=$DESTDIR --with-sysroot=/ > why this won't work? I suppose there will be some > differences in a directory layout, like no $target > dir, but otherwise it can work? The build sysroot directory needs to contain the target libraries. For example, include/ or usr/include/ (depending on how the toolchain is configured) under that directory should contain headers, lib/ or usr/lib/ should contain .a and .so files. These need to be files for the target. > You suggest --with-sysroot=$prefix/$target but I > don't understand why is so, as normally I have > (1) $prefix/bin/$target-gcc > and > (2) $prefix/$target/bin/gcc > If I set --with-sysroot=$prefix/$target then I > can get (2), but how to get (1)? I advise ignoring the files in $prefix/$target/bin/, which are nothing to do with the sysroot (they are host binaries). They aren't intended to be run directly; they're an implementation detail. Some, such as the binutils ones ($prefix/$target/bin/as etc.) may be run automatically by GCC. Others, such as $prefix/$target/bin/gcc, may be of little use (unless the compiler ends up using them when it re-execs the compiler driver when linking, which can happen in certain cases - if it does, it sets environment variables to allow it to work properly). > I think this is an rtfm point, is this sysroot trick documented > anywhere? I think it falls between the cracks of the different toolchain components. Each component documents how to configure and build that component, in isolation. But this trick is part of how you build a whole toolchain rather than part of how one component is built, so no one component is the right place to document it. Existing build systems such as crosstool-ng are a good place to look for such tricks. However, many such build systems are full of tricks that once were necessary but haven't been for many years, or approaches that still work but have long been obsolescent. When writing build-many-glibcs.py I tried to use the preferred current approach to everything and avoid those obsolescent tricks, but that only shows you one case of building toolchains for a glibc target (and without the relocation issues being discussed in this bug, as those weren't relevant for that script).
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #36 from Stas Sergeev --- (In reply to jos...@codesourcery.com from comment #35) > what you want. I'm familiar with many of the details through having > written multiple such build systems myself. But even you do make the wrong expectations. Most of your suggestions (which are very reasonable by themselves) do not work or require additional tweaks. configure reacts inadequately on them. > The non-sysroot form of configuring cross toolchains is to a large extent > considered a *legacy* way to configure such a toolchain and so has > received less attention to making it feature-complete in its interactions > with other features (e.g. building with installed libc at a different > path) because most people prefer to use sysroots. OK, that's an interesting point. I didn't know its legacy. The problem is that I still do not fully understand that route. Does --with-sysroot disable prefix, or prefix should be set to '/' explicitly? Or to something else? If I naively do --with-build-sysroot=$DESTDIR --with-sysroot=/ why this won't work? I suppose there will be some differences in a directory layout, like no $target dir, but otherwise it can work? You suggest --with-sysroot=$prefix/$target but I don't understand why is so, as normally I have (1) $prefix/bin/$target-gcc and (2) $prefix/$target/bin/gcc If I set --with-sysroot=$prefix/$target then I can get (2), but how to get (1)? I think this is an rtfm point, is this sysroot trick documented anywhere?
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #35 from joseph at codesourcery dot com --- On Tue, 8 Oct 2019, stsp at users dot sourceforge.net wrote: > As well as AS, LD and all the rest? > But that defeats the entire purpose of configure. > I need it to work on my PC, on launchpad build-farm, > and who knows where else. So I would need to write > a supplementary configure script to just fill in these > variables. Practically, building cross toolchains is complicated, with lots of separate parts (GCC, binutils, GDB, libc, etc.) that have to be built in the right order and with the right options, so you end up with some kind of script to automate the particular builds you want to do, and that adds all the required options automatically. There are several such build systems out there (e.g. crosstool-ng) that deal with this orchestration of the build of different pieces of the toolchain with appropriate options. Building an individual piece on its own (i.e., writing your own build system that deals with the different toolchain components and how to build them) requires much more understanding of the fine details of how the different configure options are specified and how to get them to achieve what you want. I'm familiar with many of the details through having written multiple such build systems myself. The non-sysroot form of configuring cross toolchains is to a large extent considered a *legacy* way to configure such a toolchain and so has received less attention to making it feature-complete in its interactions with other features (e.g. building with installed libc at a different path) because most people prefer to use sysroots.
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #34 from Stas Sergeev --- (In reply to jos...@codesourcery.com from comment #33) > to, you can also make your build system set all the variables such as CC > and CXX that are needed for the host). As well as AS, LD and all the rest? But that defeats the entire purpose of configure. I need it to work on my PC, on launchpad build-farm, and who knows where else. So I would need to write a supplementary configure script to just fill in these variables. OTOH the new option could affect it exactly the way that configure would treat the newly-built compiler as alien (as if $host!=$build) and yet get the unprefixed tools. And will not require me to evaluate the (im)proper --build with manual uname probes (in fact, I don't do uname probes, I instead grep it from the stage1 configure log and fix up with sed). Why not to fix the mess, it just seems like its broken literally everywhere we look in... (if the total lack of controlling switches can stand for being "broken").
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #33 from joseph at codesourcery dot com --- It can be useful to have the fully-prefixed host tools (but you don't need to, you can also make your build system set all the variables such as CC and CXX that are needed for the host).
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #32 from Stas Sergeev --- (In reply to jos...@codesourcery.com from comment #29) > A common way of doing that is to make $host and $build textually different > (after passing through config.sub) while still logically the same. E.g. > x86_64-pc-linux-gnu versus x86_64-unknown-linux-gnu. OK, I did the following: $ ../gnu/gcc-9.2.0/configure --disable-plugin --enable-lto --disable-libssp --disable-nls --enable-libquadmath-support --enable-version-specific-runtime-l ibs --enable-fat --enable-libstdcxx-filesystem-ts --target=i586-pc-msdosdjgpp --build=x86_64-unknown-linux-gnu --host=x86_64-pc-linux-gnu --enable-languages =c,c++ --prefix=/usr --with-build-time-tools=/home/stas/src/build-gcc/build/tm pinst/usr After which we can see in the log: configure:2360: checking build system type configure:2374: result: x86_64-unknown-linux-gnu configure:2421: checking host system type configure:2434: result: x86_64-pc-linux-gnu configure:2454: checking target system type configure:2467: result: i586-pc-msdosdjgpp ... which looks correct? But the reaction was absolutely inadequate. It started to look for fully-prefixed host tools: configure:8235: checking for x86_64-pc-linux-gnu-ar configure:8265: result: no configure:8376: checking for x86_64-pc-linux-gnu-as configure:8406: result: no configure:8517: checking for x86_64-pc-linux-gnu-dlltool configure:8547: result: no configure:8658: checking for x86_64-pc-linux-gnu-ld configure:8688: result: no And of course found nothing. If I do not explicitly specify --host, then it takes $host from $build, so no matter if I altered the --build, the $host and $build would match. So they either match, or it looks for the fully-prefixed host tools... Any solution to this one? :)
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #31 from Stas Sergeev --- (In reply to jos...@codesourcery.com from comment #29) > A common way of doing that is to make $host and $build textually different > (after passing through config.sub) while still logically the same. E.g. > x86_64-pc-linux-gnu versus x86_64-unknown-linux-gnu. And being a trick, it appears non-trivial. I would want the CPU part to be the same. I.e. x86_64-pc-linux-gnu --> x86_64-unknown-linux-gnu i686-pc-linux-gnu --> i686-unknown-linux-gnu The problem here is that I can't hard-code $host to any of that value. It must be evaluated from $build somehow. Do you have a trick also for that? Probing manually for uname before configure? Or maybe its time to add a new option after all? :)
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #30 from Stas Sergeev --- (In reply to jos...@codesourcery.com from comment #29) > A common way of doing that is to make $host and $build textually different > (after passing through config.sub) while still logically the same. E.g. > x86_64-pc-linux-gnu versus x86_64-unknown-linux-gnu. Thanks, I'll explore that and will post back in a day or 2. But... this one and your sysroot suggestion are _tricks_. I wonder why the one should use tricks for just the basic task of building a cross-compiler, this just looks strange.
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #29 from joseph at codesourcery dot com --- On Mon, 7 Oct 2019, stsp at users dot sourceforge.net wrote: > Is there any way to convince the build system that the > resulting compiler is alien and cannot be used? I think A common way of doing that is to make $host and $build textually different (after passing through config.sub) while still logically the same. E.g. x86_64-pc-linux-gnu versus x86_64-unknown-linux-gnu. Likewise if you want to configure a compiler for the same target as the host but still want it to be configured as a cross compiler, make $target textually different from $host.
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #28 from Stas Sergeev ---
(In reply to jos...@codesourcery.com from comment #22)
> The build system design is that where A and B are both built at the same
> time, and the build of B uses A, it should use the *newly built* copy of A
> as long as that is for _$host = $build_.
Indeed! I missed this "$host = $build" part initially.
When I build djgpp that _runs_ under DOS, then it is not
used during the compilation, as that would simply be impossible.
So such config is already supported.
Is there any way to convince the build system that the
resulting compiler is alien and cannot be used? I think
$host = $build check is just insufficient; there may be
more cases when the resulting compiler can't be used on
a build system, like different prefix.
If there is no such option currently, what do you think
about replacing the
if test "${build}" != "${host}"
with
if test "${build}" != "${host}" -o "$non_native_build"
or something like this?
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #27 from Stas Sergeev --- (In reply to jos...@codesourcery.com from comment #26) > On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote: > > > 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=/ > > It's --with-native-system-header-dir=/include not --with-prefix=/, but > that's the idea. Ah, yes, indeed. So can I assume that in the -isystem path and -B path, the sysroot part will be swapped with the build_sysroot during build? If so, then I would finally understand your sysroot suggestion. But there are still 2 more suggestions, yours and mine, and I am not sure what is to do with them. I think your suggestion is to add something like --with-build-time-prefix to be able to specify the alternative location of headers and libs for non-sysroot build. Mine is to add --with-build-time-compiler=dir. I think we can have both, and I can try to implement mine (--with-build-time-compiler) if you think this is acceptable (i.e. the _possibility_ to add an extra build stage is acceptable).
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #26 from joseph at codesourcery dot com --- On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote: > 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=/ It's --with-native-system-header-dir=/include not --with-prefix=/, but that's the idea.
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #25 from Stas Sergeev --- (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.
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #24 from joseph at codesourcery dot com --- On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 > > --- Comment #23 from Stas Sergeev --- > (In reply to jos...@codesourcery.com from comment #22) > > On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote: > > And overriding like that is fundamentally unsafe, because in general in a > > multi-stage build (such as for a cross to GNU/Linux where the first stage > > is a static-only C-only compiler) the libraries have to be built with the > > more-fully-featured compiler built in the same stage - not with the > > previous stage's compiler. > > 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. (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.) > > Then maybe an option is needed to find both headers and libraries in the > > non-sysroot case (where the option for libraries gives the top-level > > directory under which subdirectories for each multilib, using the multilib > > OS suffix, can be found). An option to find the build-time equivalent of > > $exec_prefix/$target, with lib and include subdirectories, say. > > And then why such an option is not called --with-build-sysroot? > In comment #11 you say > "there is no non-sysroot-headers equivalent of --with-build-sysroot", > but I don't understand what do you mean. Can we use --with-build-sysroot > w/o --with-sysroot, making it exactly an option you describe > above? 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. Otherwise, you can still use them, but need such symlinks during the build process. That is, --with-build-sysroot already works for the sort of thing you want to do, provided (a) you have the usr -> . symlink and (b) you configure using --with-sysroot even though it's logically not a sysrooted toolchain.
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #23 from Stas Sergeev --- (In reply to jos...@codesourcery.com from comment #22) > On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote: > And overriding like that is fundamentally unsafe, because in general in a > multi-stage build (such as for a cross to GNU/Linux where the first stage > is a static-only C-only compiler) the libraries have to be built with the > more-fully-featured compiler built in the same stage - not with the > previous stage's compiler. 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. > Then maybe an option is needed to find both headers and libraries in the > non-sysroot case (where the option for libraries gives the top-level > directory under which subdirectories for each multilib, using the multilib > OS suffix, can be found). An option to find the build-time equivalent of > $exec_prefix/$target, with lib and include subdirectories, say. And then why such an option is not called --with-build-sysroot? In comment #11 you say "there is no non-sysroot-headers equivalent of --with-build-sysroot", but I don't understand what do you mean. Can we use --with-build-sysroot w/o --with-sysroot, making it exactly an option you describe above? > The build system design is that where A and B are both built at the same > time, and the build of B uses A, it should use the *newly built* copy of A Lets do A --> B' --> B then. :) > "make all-target-libstdc++-v3" or whatever). In general, if you don't > want to build with the newly built copy of A you should configure and > build in such a way that there isn't a newly built copy of A at all. Mm, yes, I was thinking about renaming the dirs during build to hide stuff from configure, but decided against doing so as being too hackish. Would you suggest this way for the wide adoption?
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #22 from joseph at codesourcery dot com --- On Thu, 3 Oct 2019, stsp at users dot sourceforge.net wrote: > - 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. And overriding like that is fundamentally unsafe, because in general in a multi-stage build (such as for a cross to GNU/Linux where the first stage is a static-only C-only compiler) the libraries have to be built with the more-fully-featured compiler built in the same stage - not with the previous stage's compiler. > > 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 Then maybe an option is needed to find both headers and libraries in the non-sysroot case (where the option for libraries gives the top-level directory under which subdirectories for each multilib, using the multilib OS suffix, can be found). An option to find the build-time equivalent of $exec_prefix/$target, with lib and include subdirectories, say. The build system design is that where A and B are both built at the same time, and the build of B uses A, it should use the *newly built* copy of A as long as that is for $host = $build. That applies for in-tree binutils (to the extent that anyone still builds those in a unified tree), and for in-tree host parts of GCC, and for in-tree libgcc when other target libraries use it, and so on - it's the universal design in the build system for all such dependencies. It may be possible to hack things up to allow configuring and building an individual target library with an installed compiler, but that's a case where the tree in which you build that library is *not* one in which you've built host GCC at all (and then you pass a load of variables to "make all-target-libstdc++-v3" or whatever). In general, if you don't want to build with the newly built copy of A you should configure and build in such a way that there isn't a newly built copy of A at all.
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879
--- Comment #21 from Stas Sergeev ---
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.
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #20 from joseph at codesourcery dot com --- The only case where the newly built GCC should be overridden is the Canadian cross case, and while that does use a pre-installed tool from the PATH, it's best to use "make all-host" in that case to avoid rebuilding target libraries and instead copy them from the build system. (The identically-configured build-x-target tools still need to be in the PATH in that case because the GCC build wants to run the target compiler with -dumpspecs.) Your problem as originally described was with finding non-sysroot headers. 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. Maybe you don't want --with-headers because of the side-effect of copying into a sys-include directory, but something quite similar to that but without that side-effect might work.
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #19 from Stas Sergeev --- OK, but the setup when you want to override the newly-built gcc, is also needed. Like, when you want to build the "destdir" gcc with the one installed directly into prefix (and therefore working fine on host). Would you suggest a new option for that? I've seen the variables CC_FOR_TARGET and alike, but they do not work that way too. So I think currently there is no way of doing that, and so some patch should be created. How should it look like?
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #18 from joseph at codesourcery dot com --- No, --with-build-time-tools definitely should not override newly built tools. For example, in some bootstrap configurations you have to build GCC more than once. If you're also installing into a DESTDIR rather than directly into the configured prefix, you need to use --with-build-time-tools so that binutils for the target can be found. But when building the second GCC, the newly built GCC *must* be used to compile its own shared libraries, not the first-stage GCC that might be installed alongside binutils in the directory pointed to with --with-build-time-tools. (For example, the second GCC might be configured --enable-shared, with that being needed to build shared libgcc and libstdc++, where the first GCC was configured --disable-shared.)
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 --- Comment #17 from Stas Sergeev --- Created attachment 46991 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46991=edit the fix Attached is the patch that I think is correct. It also seems to work properly, i.e. the full build process passes (previous patches were only tested for the part of the build process that was failing). This patch allows --with-build-time-tools= to override the in-tree compiler, which I think this option is for. Please let me know if it is good or bad.
[Bug other/91879] --with-build-time-tools doesn't work as expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91879 Stas Sergeev changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |--- Summary|--with-build-sysroot|--with-build-time-tools |doesn't work as expected|doesn't work as expected
