On 2026/01/26 18:14, Rafael Sadowski wrote: > On Mon Jan 26, 2026 at 02:44:39PM +0000, Stuart Henderson wrote: > > On 2026/01/26 15:23, Rafael Sadowski wrote: > > > On Mon Jan 26, 2026 at 03:05:32PM +0100, Claudio Jeker wrote: > > > > ports-gcc is modern enough to support -flto but our binutils and ld in > > > > base are not. So compiles break whenever lto is enabled on archs like > > > > sparc64. > > > > > > > > This diff disables -flto and -fno-fat-lto-objects for OpenBSD which is > > > > maybe a big hammer but the simplest fix I came up with. > > > > > > We could hide it with MODCMAKE_PORT_BUILD like. MODCMAKE_PORT_BUILD > > > only defined during ports build. This changes the behaviour only for > > > ports, but not for end users, who receive it as expected by cmake > > > behaviour. > > > > Whether it's a ports build or not, LTO will not work with the old > > ld.bfd that's in base, so this is a compatibility fix and needed for > > any use whether that's in ports builds or not, this differs from > > the usual things that get hidden behind MODCMAKE_PORT_BUILD. > > You cannot know what someone is doing with cmake under OpenBSD and which > linkers etc. they are using. You may want to use GCC15 and a wip-linker. > Unlikely, but possible. > > > > > The best fix for cmake would be to check the linker version as well > > as the compiler version before enabling LTO, I think (and that is > > probably valid to go upstream). > > Agree. > > > But if that's too awkward then > > Claudio's diff seems reasonably targetted (though will disable LTO > > in some cases where it works - i.e. a ports-gcc build on an arch > > using ld.lld). > > > > Yes, see above >
But disabling LTO in some unlikely corner cases seems better than breaking the build in some more-common caes..
