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
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
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 ++
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
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
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
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
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
This macro deduplicates the
$CC -v 2>&1 | sed -n 's/^Thread model: //p'
check that was occurring in various runtime libs.
Additionally, as a bit of an Easter egg, this also allows overriding
what the compiler would return by setting the
`gcc_cv_target_t
at 11:02 AM, John Ericson wrote:
> Hello, this 4-year-old patch of mine was never reviewed. Per
> https://github.com/NixOS/nixpkgs/pull/414299, we in a package set / distro,
> Nixpkgs/NixOS, just began (albeit on an experimental basis) packaging GCC
> with this patch (among others)
there, so a good one to start with. (I think it would be unnecessary
complicated to discuss them all at once.)
Thanks in advance,
John
On Wed, Aug 18, 2021, at 4:38 PM, John Ericson wrote:
> From: John Ericson
>
> Previously, they always scraped the thread mode from `$CC -v', now,
This dates back to the creation of top-level `libgcc` in
fa9585134f6f58fa0d3da3ca4ad5493855aea2dc. I strongly suspect that this
does nothing.
(For context, my overall goal here is hoping libgcc can depend on
fewer/no stuff that is generated by `gcc/Makefile`. This is me trying to
pluck some low-ha
This dates back to the creation of top-level `libgcc` in
fa9585134f6f58fa0d3da3ca4ad5493855aea2dc. I strongly suspect that this
does nothing.
Andrew Pinksi adds:
> So looking into this further, MACHMODE_H used part of LIBGCC_DEPS
> because of TM_H and r0-78222-gfa9585134f6f58 moved away from incl
This macro deduplicates the
$CC -v 2>&1 | sed -n 's/^Thread model: //p'
check that was occurring in various runtime libs.
Additionally, as a bit of an Easter egg, this also allows overriding
what the compiler would return by setting the
`gcc_cv_target_thread_file` cache variable first. I adm
From: John Ericson
My goal is to be able to build libgcc cleanly in isolation --- today one
needs to figure `make ...` misc things in the gcc subdir.
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, this
commit moves the NO_PIE_C
From: John Ericson
My goal is to be able to build libgcc cleanly in isolation --- today one
needs to figure `make ...` misc things in the gcc subdir.
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, this
commit moves the NO_PIE_C
From: John Ericson
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, just
use the output of:
$(CC) -print-sysroot
It is just used in one spot, in an AIX code-path. I just made (within
make) a shell variable to use instead.
I
From: John Ericson
My goal is to be able to build libgcc cleanly in isolation --- today one
needs to figure `make ...` misc things in the gcc subdir.
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, this
commit moves the NO_PIE_C
From: John Ericson
Following Andrew Pinski's suggestions in
https://gcc.gnu.org/pipermail/gcc-patches/2025-July/689683.html, just
use the output of:
$(CC) -print-sysroot
It is just used in one spot, in an AIX code-path. I just made (within
make) a shell variable to use instead.
I
* Makefile.in: Use regular libdir/includedir, no more libsubdir
etc.
* config/t-slibgcc-vms: Use regular libdir, no more libsubdir.
* configure: Regenerate.
* configure.ac: Stash away the passed libdir as orig_libdir, and
define libdir and includedir to matc
libdir as orig_libdir, and
define libdir and includedir to match what Makefile.in used to
do.
Signed-off-by: John Ericson
---
libssp/Makefile.am | 6 +--
libssp/Makefile.in | 113 +---
libssp/configure| 12 +++--
libssp/configure.ac
> and "get those settings passed down from top level" is one plausible end
> state - sharing logic implicitly that way rather than expanding it all
> locally in each target library configure script, even if expanding it
> locally for each library is useful as an intermediate stage.)
Correct m
make variable via autoconf
substitution.
* configure: Regenerate.
* configure.ac: New configure check to define NO_PIE_CFLAGS
using the algorithm Andrew asked for in the linked mail.
Suggested-by: Andrew Pinski
Signed-off-by: John Ericson
---
gcc/Makefile.in
This macro deduplicates the
$CC -v 2>&1 | sed -n 's/^Thread model: //p'
check that was occurring in various runtime libs.
Additionally, as a bit of an Easter egg, this also allows overriding
what the compiler would return by setting the
`gcc_cv_target_thread_file` cache variable first. I adm
On Mon, Aug 4, 2025, at 4:02 PM, Joseph Myers wrote:
> On Sun, 3 Aug 2025, John Ericson wrote:
>
> > > and "get those settings passed down from top level" is one plausible
> > > end state - sharing logic implicitly that way rather than expanding it
> &
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
26 matches
Mail list logo
