toolchain.eclass: rework bootstrapping logic #33114
Conversation
thesamesam
force-pushed
the
toolchain-eclass
branch
from
67d0793
to
d33fc32
Compare
Pull Request assignmentSubmitter: @thesamesam @gentoo/github Linked bugsBugs linked: 840392, 914881, 477548, 831423 New packagesThis Pull Request appears to be introducing new packages only. Due to limited manpower, adding new packages is considered low priority. This does not mean that your Pull Request will not receive any attention, however, it might take quite some time for it to be reviewed. In the meantime, your new ebuild might find a home in the GURU project repository: the ebuild repository maintained collaboratively by Gentoo users. GURU offers your ebuild a place to be reviewed and improved by other Gentoo users, while making it easy for Gentoo users to install it and enjoy the software it adds. In order to force reassignment and/or bug reference scan, please append Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide |
gentoo-bot
added
need assignment
Pull request CI reportReport generated at: 2023-09-28 23:55 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Pull request CI reportReport generated at: 2023-09-29 00:10 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
thesamesam
force-pushed
the
toolchain-eclass
branch
from
d33fc32
to
5ef0fe6
Compare
* Build stage1 compiler with user's CFLAGS. This consistently ends up saving at least 15 minutes for me on a fast amd64 machine and should save more on slower machines and architectures. There's only any risk here if the host compiler is ancient/very buggy and even then, you get a failed bootstrap later on. The GCC developers, per the linked bug, end up using STAGE1_CFLAGS="-O2" anyway to speed up the process so it's not like this is untested at all. mattst88 actually brought this up.. 10 years ago (bug #477548). Let's try make that right now. * Respect LDFLAGS for target libraries for native builds. Not touching this for cross builds, at least for now, as it's a bit more delicate. (Unfortunately, we have to put a hack in here for now until we can fix multilib.eclass - see bug #914881). Bug: https://gcc.gnu.org/PR111619 Bug: https://bugs.gentoo.org/914881 Closes: https://bugs.gentoo.org/477548 Closes: https://bugs.gentoo.org/831423 Closes: https://bugs.gentoo.org/840392 Apologies-to: Matt Turner <mattst88@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org>
Upstream are fine with bootstrapping with -O3, so don't strip it out if the user set it, even with USE=-custom-cflags. Signed-off-by: Sam James <sam@gentoo.org>
thesamesam
force-pushed
the
toolchain-eclass
branch
from
5ef0fe6
to
1ce9d74
Compare
Pull request CI reportReport generated at: 2023-09-29 00:55 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Pull request CI reportReport generated at: 2023-09-29 01:10 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
* Pass --disable-fixincludes for newer GCCs for USE=jit (still need to try disable it in general when we can, but we had to turn it on for a bit because of newer glibc) as it's pointless there. * Disable a bunch of other options for the JIT build, imported from my local script for bisecting GCC. * While at it, use an array for the configure args for the JIT build and just use emake -C. Signed-off-by: Sam James <sam@gentoo.org>
Pull request CI reportReport generated at: 2023-09-29 01:50 UTC There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
|
Merged |
|
@thesamesam |
Could you file a Gentoo bug please with emerge --info and the gcc build log tarball the ebuuld creates? Thanks. |
|
@thesamesam |
toolchain.eclass: rework bootstrapping logic
Build stage1 compiler with user's CFLAGS. This consistently ends up
saving at least 15 minutes for me on a fast amd64 machine and should save
more on slower machines and architectures.
There's only any risk here if the host compiler is ancient/very buggy and
even then, you get a failed bootstrap later on. The GCC developers, per the
linked bug, end up using STAGE1_CFLAGS="-O2" anyway to speed up the process
so it's not like this is untested at all.
mattst88 actually brought this up.. 10 years ago (bug #477548). Let's try
make that right now.
Respect LDFLAGS for target libraries for native builds. Not touching this
for cross builds, at least for now, as it's a bit more delicate.
(Unfortunately, we have to put a hack in here for now until we can fix
multilib.eclass - see bug #914881).
Bug: https://gcc.gnu.org/PR111619
Bug: https://bugs.gentoo.org/914881
Closes: https://bugs.gentoo.org/477548
Closes: https://bugs.gentoo.org/831423
Closes: https://bugs.gentoo.org/840392
Apologies-to: Matt Turner mattst88@gentoo.org
Signed-off-by: Sam James sam@gentoo.org