On Sat, Dec 23, 2023 at 04:09:35AM +0100, Rafael Sadowski wrote:
> On Sat Dec 23, 2023 at 03:54:11AM +0100, Rafael Sadowski wrote:
> > On Sat Dec 23, 2023 at 12:27:05AM +0100, Theo Buehler wrote:
> > > emulators/citra was broken with the update to boost 1.84. net/nheko
> > > broke with the llvm 16 update (in fact it broke with llvm 15 when kn
> > > updated mtxclient and nheko in February). Most recently, libquotient
> > > broke on aarch64. The symptom is always the same cryptic message:
> > >
> > > /usr/include/c++/v1/__bsd_locale_fallbacks.h:110:5: error: non-const lvalue reference to type '__builtin_va_list' cannot bind to a value of unrelated type 'va_list' (aka 'std::__va_list')
> > > va_start(__va, __format);
> > > ^~~~~~~~~~~~~~~~~~~~~~~~
> > > /usr/include/stdarg.h:34:47: note: expanded from macro 'va_start'
> > > #define va_start(ap, last) __builtin_va_start((ap), last)
> > >
> > > http://build-failures.rhaalovely.net/aarch64/2023-12-20/x11/libquotient.log
> > >
> > > In all three ports, a line such as
> > >
> > > -Xclang -include-pch -Xclang /usr/ports/pobj/nheko-0.11.3/build-amd64/CMakeFiles/nheko.dir/cmake_pch.hxx.pch
> > >
> > > appears. And indeed, the diff below (which is a workaround at best)
> > > makes all three ports build.
> > >
> > > There are a few questions that should probably be answered:
> > >
> > > - why did citra break with the boost update?
> > > - is this a cmake bug or a clang bug?
> >
> > I don't think it's a cmake bug. IMO It's an pre compiled header issue.
Yes. What I was trying to get at is that ideally we figure out the root
cause for the breakage. Otherwise we'll just paper over the underlying
issue with workarounds and at some point they will no longer work and we
will be none the wiser.
So far I have only found where to look, which is one step, but there's
more to be done. Why can an update to boost trigger this? Why can I
build libquotient on my amd64 laptop but not on arm64, both with
up-to-date ports and an up-to-date ports tree? What recent change caused
this? Was this the boost update?
> >
> > >
> > > But maybe it gives someone a clue what the right fix might be.
> > >
> > > Index: emulators/citra/Makefile
> > > ===================================================================
> > > RCS file: /cvs/ports/emulators/citra/Makefile,v
> > > diff -u -p -r1.29 Makefile
> > > --- emulators/citra/Makefile 19 Dec 2023 06:18:03 -0000 1.29
> > > +++ emulators/citra/Makefile 22 Dec 2023 23:15:14 -0000
> > > @@ -1,6 +1,3 @@
> > > -# broken with boost 1.84
> > > -BROKEN= cannot initialize '__va_list_tag *' with 'va_list'
> > > -
> > > # ships a dynarmic copy, and dynarmic only supports x86-64 and AArch64
> > > ONLY_FOR_ARCHS = amd64 arm64
> > >
> > > @@ -56,7 +53,8 @@ CONFIGURE_ARGS = -DENABLE_CUBEB=OFF \
> > > -DUSE_SYSTEM_SDL2=ON \
> > > -DENABLE_FFMPEG_AUDIO_DECODER=ON \
> > > -DENABLE_FFMPEG_VIDEO_DUMPER=ON \
> > > - -DCITRA_USE_PRECOMPILED_HEADERS=OFF
> >
> > This was not complete . There is a second option:
> > DYNARMIC_USE_PRECOMPILED_HEADERS.
> >
> > I think CMAKE_DISABLE_PRECOMPILE_HEADERS is the big hummer to disabled
> > all pre complied header even if there are hand-made options.
> >
> > https://cmake.org/cmake/help/latest/variable/CMAKE_DISABLE_PRECOMPILE_HEADERS.html
> >
> > The following diff compiles without issues:
This does sound like the better workaround. But why were precompiled
headers disabled in this port and why do they need harder disabling now?
> > > Index: x11/libquotient/Makefile
> > > ===================================================================
> > > RCS file: /cvs/ports/x11/libquotient/Makefile,v
> > > diff -u -p -r1.6 Makefile
> > > --- x11/libquotient/Makefile 11 Oct 2023 18:40:14 -0000 1.6
> > > +++ x11/libquotient/Makefile 22 Dec 2023 23:02:46 -0000
> > > @@ -27,7 +27,8 @@ LIB_DEPENDS = devel/olm \
> > > CONFIGURE_ARGS = -DBUILD_SHARED_LIBS=ON \
> > > -DCMAKE_DISABLE_FIND_PACKAGE_Git=ON \
> > > -DQuotient_ENABLE_E2EE=ON \
> > > - -DQuotient_INSTALL_TESTS=OFF
> > > + -DQuotient_INSTALL_TESTS=OFF \
> > > + -DCMAKE_DISABLE_PRECOMPILE_HEADERS=ON
>
> Maybe GCC is happy. Again, I think it's a PCH issue ;)
But surely gcc isn't an option. We can't mix multiple c++ standard
libraries in a port.
>
> libQuotient-0.8.1.2/CMakeLists.txt:
>
> 310 # Don't use PCH w/GCC (https://bugzilla.redhat.com/show_bug.cgi?id=1721553#c34)
> 311 if (NOT CMAKE_CXX_COMPILER_ID STREQUAL GNU)
> 312 target_precompile_headers(${QUOTIENT_LIB_NAME} PRIVATE Quotient/converters.h)
> 313 endif ()
>
> > >
> > > # XXX C++20 vs. libstd++ in quotest.cpp
> > > CONFIGURE_ARGS += -DBUILD_TESTING=OFF
> >
> > Which brings me to a more common questions. Does PCH make sense in the
> > ports? I don't think so! Does it make sense to enable the big (cmake)
> > hummer by default?
> >
>
> It is good to know that you should search for PCH in cmake files if the error
> message becomes really strange.
Hopefully this isn't going to be needed.
No comments:
Post a Comment