Problem found when building net-p2p/qbittorrent on FreeBSD 12.1-RELEASE-p1 r354992 GENERIC powerpc 32 bit, running on Apple Powerbook 17". /usr/ports/net-p2p/qbittorrent # make install clean ===> Building for qbittorrent-4.2.3 cd src/ && ( test -e Makefile || /usr/local/lib/qt5/bin/qmake -o Makefile /usr/ports/net-p2p/qbittorrent/work-default/qbittorrent-4.2.3/src/src.pro QMAKE_LRELEASE= ) && /usr/bin/make -f Makefile all compiling app/application.cpp In file included from app/cmdoptions.h:39, from app/application.h:51, from app/application.cpp:30: ./base/tristatebool.h: In constructor 'TriStateBool::TriStateBool(bool)': ./base/tristatebool.h:44:5: error: 'constexpr' constructor does not have empty body 44 | } | ^ *** [application.o] Error code 1 make[3]: stopped in /usr/ports/net-p2p/qbittorrent/work-default/qbittorrent-4.2.3/src 1 error make[3]: stopped in /usr/ports/net-p2p/qbittorrent/work-default/qbittorrent-4.2.3/src *** [sub-src-all] Error code 2 make[2]: stopped in /usr/ports/net-p2p/qbittorrent/work-default/qbittorrent-4.2.3 1 error make[2]: stopped in /usr/ports/net-p2p/qbittorrent/work-default/qbittorrent-4.2.3 ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1
(In reply to canardo from comment #0) What compiler is used? You need to report this to the qBittorrent upstream (https://github.com/qbittorrent/qBittorrent/issues).
(In reply to Yuri Victorovich from comment #1) # cc --version cc (GCC) 4.2.1 20070831 patched [FreeBSD] I guess it is the one in use. Or is there another way to check ? I'll report the problem to qBittorrent on github.
(In reply to canardo from comment #2) Yes, please do. Please also try to build with clang. If this works we can force clang for qBittorrent, I guess.
Why is gcc-4.2.1 from 20070831 used on powerpc? Why not use a newer gcc or clang?
(In reply to Yuri Victorovich from comment #4) Just a note mostly about clang vs. powerpc64 and 32-bit powerpc . . . Head (13) is using llvm/clang and 4.2.1 gcc and related materials have been removed from there. But using llvm involves powerpc64 ABI changes (incompatible) and use of llvm 10 materials (in order for clang and such to fully work). Even now there is a pending ABI fix for 32-bit powerpc from llvm having a change in what it does that no longer matches (modern) gcc when targeting FreeBSD: https://bugs.llvm.org//show_bug.cgi?id=40736 The powerpc64 and 32-bit powerpc ABIs for stable/12 and stable/11 (and related releases) can not be changed at this point. So it will be some time before all supported FreeBSD versions have dropped 4.2.1 related materials as the system compiler/toolchain (the default toolchain, for building ports on stable/12 and stable/11). Unfortuantely, devel/llvm* ports have the same sort of problems for powerpc64 and 32-bit powerpc as the historical ones that blocked llvm's general use in such contexts: even llvm10, when not configured to use the updated ABI(s) that head is based on, has such issues if I understand right. (The above is an overall summary only.) As for GCC . . . Modern GCC's licensing limits where/how it is used in FreeBSD contexts, even if there were no technical problems for powerpc64 or 32-bit powerpc.
(In reply to Yuri Victorovich from comment #1) reported to qBittorrent github: https://github.com/qbittorrent/qBittorrent/issues/12437
There is no indication that anything is wrong with the port itself. The upstream issue is about the compiler check in their cmake scripts. Please reopen if you feel that something should be fixed in the port.