[Bug 263353] lang/python38: fix excessive ld.lld memory use with LTO in port options

From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 24 Apr 2022 23:03:23 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=263353

Kubilay Kocak <koobs@FreeBSD.org> changed:

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

--- Comment #5 from Kubilay Kocak <koobs@FreeBSD.org> ---
(In reply to Matthias Andree from comment #4)

That's not how this works Matthias. Just like you'd like people to respect your
time, everyone else also appreciates you respecting theirs, particularly as
they spent time and effort on your bug reports.

There are multiple considerations here:

1) with-lto supports =thin argument, but it was only set in python311 in ports
9a31e1b6d3 because support for =thin was not backported to earlier branches. I
asked in comment 1 for a test of whether you can link with =thin -g as that
(thin), along with decoupling our LTo build from Pythons lto option is the most
desirable target state

2) Bug 261974 added support via Pythons build system flag for LTO, not using
our own toolchain flags. This means we were necessarily coupled to what Python
does with this flag. That commit landed somewhat prematurely prematurely and we
are now dealing with that.

2) Adding -g in the LTO was added a while ago [1][2], and earlier than 3.8, and
affects multiple Python port versions

3) The definition and scope of 'debug' in freebsd ports isn't an exact overlap
with upstreams definitions of 'debug' (not just compile args).

4) Python without compelling arguments/cases to the contrary prefers to remain
as close to upstream as possible, and where changes need to be made, changes
are submitted for upstream inclusion/improvement unless that is impossible.

We're not asking that you care about all of the above, but these are the things
we need to consider, along with the overhead of carrying local patches, where
alternatives may (and do) exist.

[1]
https://github.com/python/cpython/commit/1bb9dd337ed5aa9eafc8e2ce017ceedf044145e3
[2] https://github.com/python/cpython/issues/74530

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