[Bug 264949] lang/gcc11: Needs build time warning for /tmp consumption

From: <bugzilla-noreply_at_freebsd.org>
Date: Wed, 29 Jun 2022 23:23:06 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264949

Lorenzo Salvadore <salvadore@freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugs.freebsd.org/bu
                   |                            |gzilla/show_bug.cgi?id=2619
                   |                            |77

--- Comment #11 from Lorenzo Salvadore <salvadore@freebsd.org> ---
(In reply to Tomoaki AOKI from comment #0)

> Is this because of LTO_BOOTSTRAP option (default of amd64)?

I think you might be right about it. Have you tried compiling the port with
STANDARD_BOOTSTRAP instead? What about without any bootstrap option?

See also bug #261977, which contains a reference to commit
https://cgit.freebsd.org/ports/commit/?id=aadf6428cc480fbeda72ec90d53ef340e95f49ca
that recently introduced LTO_BOOTSTRAP as default.

(In reply to Piotr Kubaj from comment #2)

If the issue is indeed LTO, we could add a warning as you suggested. I think it
would be nice to introduce it as a pkg-help file, which is displayed when
choosing options and should explain that, if the machine is not powerful
enough, the default option should be changed to disable LTO_BOOTSTRAP.

On the other hand, we could also change the default options, as you already did
in some architectures. We would lose the optimiziation in prebuilt packages,
but I don't know how much is it worth it: I think we are risking that many
people that compile their ports with poudriere without modifying port options
would get into trouble... Is the performance improvement using LTO really
significant? If not, I would renounce to it for the sake of convenience.
Another possibility could be to have separate ports or flavors: one without LTO
and one with LTO, but maintaining all the versions of GCC that we already have
seems complex enough, I don't think it is wise to increase complexity.

-- 
You are receiving this mail because:
You are the assignee for the bug.