On Mon Jan 26, 2026 at 08:32:22PM +0100, Claudio Jeker wrote:
> On Mon, Jan 26, 2026 at 08:16:40PM +0100, Rafael Sadowski wrote:
> > On Mon Jan 26, 2026 at 05:52:00PM +0000, Stuart Henderson wrote:
> > > 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..
> > >
> >
> > Then let's add a message 'message(WARNING "")' instead of "# nothing",
> > please.
> >
> > https://cmake.org/cmake/help/v3.5/command/message.html
>
> Since this only hit doxygen in ports (at least it seems to not be a
> widespread issue) I wonder if this can be fix somewhere in doxygen
> cmake files.
>
> It seems the LTO flags are only in CMAKE_${lang}_COMPILE_OPTIONS_IPO but I
> have not yet figured out where those are pulled into doxygen
>
> --
> :wq Claudio
I think you want this:
diff --git a/devel/doxygen/Makefile b/devel/doxygen/Makefile
index 757db6e1e65..34f787c3ab9 100644
--- a/devel/doxygen/Makefile
+++ b/devel/doxygen/Makefile
@@ -3,6 +3,7 @@ COMMENT= source code documentation generator tool
VERSION= 1.15.0
DISTNAME= doxygen-${VERSION}.src
PKGNAME= doxygen-${VERSION}
+REVISION= 0
CATEGORIES= devel textproc
diff --git a/devel/doxygen/patches/patch-CMakeLists_txt
b/devel/doxygen/patches/patch-CMakeLists_txt
new file mode 100644
index 00000000000..ad77afce3d0
--- /dev/null
+++ b/devel/doxygen/patches/patch-CMakeLists_txt
@@ -0,0 +1,13 @@
+Index: CMakeLists.txt
+--- CMakeLists.txt.orig
++++ CMakeLists.txt
+@@ -36,9 +36,6 @@ option(enable_coverage "Enable coverage reporting for
+ option(enable_tracing "Enable tracing option in release builds
[development]" OFF)
+ option(enable_lex_debug "Enable debugging info for lexical scanners in
release builds [development]" OFF)
+
+-if(CMAKE_BUILD_TYPE STREQUAL "Release")
+- set(CMAKE_INTERPROCEDURAL_OPTIMIZATION TRUE)
+-endif()
+
+ include(CheckCXXCompilerFlag)
+
