Previously, they always scraped the thread mode from `$CC -v', now, that
is the default but one may pass `--with-threads=MODEL` to be explicit
instead.
One use-case is bootstraping with a shorter critical path. The
traditionally route was to build an entire "static stage" GCC, build
libc, and then
From: John Ericson
Previously, they always scraped the thread mode from `$CC -v', now, that
is the default but one may pass `--with-threads=MODEL` to be explicit
instead.
One use-case is bootstraping with a shorter critical path. The
traditionally route was to build an entire "static
We will use this in the subsequent diff to control what basenames we
search for. In machine-specific subdirectories, we should just look for
the original basename, but in machine-agnostic subdirectories, we might
additionally look for prefixed disambiguated names, as an alternate
method of keeping
This matches the behavior of Clang, and makes it easier to work with
cross compilers without heeding to hard-code paths at build time.
---
gcc/gcc.c | 78 ---
1 file changed, 68 insertions(+), 10 deletions(-)
diff --git a/gcc/gcc.c b/gcc/gcc.c
i
This means, we might search for:
- path/$machine/$version/prog
- path/$machine/prog
- path/$machine-prog
But not
- path/$machine/$version/$machine-prog
because disambiguating $machine twice is unnecessary.
This does mean we less liberal in what we accept than LLVM, but that's
OK. The down side
OK I have polished off my code in light of previous discussion and will
submit it in follow-up emails.
As mentioned before, this patch series is on top of the
non-behavior-changing cleanup I previously submitted in
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/576725.html
The first patch
The helper is for `--print-prog-name` and similar things. Since all
executable finding goes through it, we can move the default overrides
into that path too. This also ensures that if some is looking for a
*non*-program that called `as`, `ld`, etc., weird things don't happen.
---
gcc/gcc.c | 59 ++
On 07/30/18 19:48, Joseph Myers wrote:
On the contrary, I think an important principle here is that non-multilib
and multilib builds follow the same code paths as far as possible, with
the multilib variables just set to trivial values (modulo osdirname) in
the case of a non-multilib build - a non
apologies.]
From 3e0e7d6e5cfdc46342fcad5fe6b24b4f47af0d87 Mon Sep 17 00:00:00 2001
Message-Id:
<3e0e7d6e5cfdc46342fcad5fe6b24b4f47af0d87.1532988611.git.John.Ericson@Obsidian.Systems>
From: John Ericson
Date: Mon, 30 Jul 2018 18:06:02 -0400
Subject: [PATCH] multilib: Don't bother with multilib configurat
