Date: Wed, 23 Feb 2022 03:06:18 +0000 From: bugzilla-noreply@freebsd.org To: python@FreeBSD.org Subject: [Bug 261974] lang/python311: Enable Link Time Optimization (via autoconf) Message-ID: <bug-261974-21822-CySc2ieXhW@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-261974-21822@https.bugs.freebsd.org/bugzilla/> References: <bug-261974-21822@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D261974 Kubilay Kocak <koobs@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|lang/python311: add |lang/python311: Enable Link |--enable-lto |Time Optimization (via | |autoconf) Keywords| |needs-patch, needs-qa --- Comment #5 from Kubilay Kocak <koobs@FreeBSD.org> --- (In reply to Piotr Kubaj from comment #4) Sounds reasonable. Could we: - Wrap this in an LTO option, enabled by default, excluded on architectures= its not relevent or ok for. - Update the patch to include changes for all lang/python* ports that suppo= rt it (LTO). I think more than one does. - Can we get away without the 'CC=3D environment override', leaving in eith= er: 1) the current check for =3D=3D cc, or=20 2) using appropriate ports framework mechanisms to determine whether the compiler is clang? ie: if excluding options based on arch is feasible: if option and correct-compiler=20 If not: if option and correct compiler and not bad-arch Note that while pythons configure checks CC, it also incorrectly detects 'G= NU linker' (based on version string), and the build system is not very robust = with respect to toolchains, and if we can just do the 'is this the right toolcha= in for lto' parts in ports, that would be preferable. --=20 You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-261974-21822-CySc2ieXhW>