Recent ports tree update (at r509423) results in an update of port LibreOffice 6.2.5 -> 6.3.0, which fails with the compiler error shown below: [...] [CXX] vcl/qt5/Qt5Object.cxx /usr/ports/editors/libreoffice/work/libreoffice-6.3.0.4/vcl/qt5/Qt5Instance.cxx:416:25: error: no viable constructor or deduction guide for deduction of template arguments of 'function' RunInMainThread(std::function([&, this]() { pPicker = createPicker(context, eMode); })); ^ /usr/include/c++/v1/functional:1427:48: note: candidate template ignored: could not match 'function<_Fp>' against '(lambda at /usr/ports/editors/libreoffice/work/libreoffice-6.3.0.4/vcl/qt5/Qt5Instance.cxx:416:39)' template<class _Fp> class _LIBCPP_TEMPLATE_VIS function; // undefined [...] Recompiling/updating ALL qt5-* ports or updating the ports tree and updating installed ports (traditional make variant) prior to the update of port editor/libreoffice doesn't result in a successful build.
(In reply to O. Hartmann from comment #0) Which version of FreeBSD are you using? I did test in pourdiere in 12.0 and 11.3, amd64 and i386. May I suggest you updating all the depends ports to the latest version? You can obtain the list via `make all-depends-list`
I bet O.Harmann is on 13.0.
(In reply to Walter Schwarzenfeld from comment #2) That should also be fine, my desktop is 13 and I updated it and test again right before committing.
The failure happens on 13-CURRENT (r351229) and on 12-STABLE (last updated on Monday, revision at this moment not accessible due to off site).
qt5 is per default off.
12.0-p9 amd64 and i386 - same error.
(In reply to VVD from comment #6) OPTIONS_FILE_SET+=CUPS OPTIONS_FILE_SET+=DOCS OPTIONS_FILE_UNSET+=GNOME OPTIONS_FILE_UNSET+=GTK2 OPTIONS_FILE_UNSET+=GTK3 OPTIONS_FILE_SET+=JAVA OPTIONS_FILE_SET+=KDE5 OPTIONS_FILE_SET+=MMEDIA OPTIONS_FILE_UNSET+=PGSQL OPTIONS_FILE_SET+=QT5 OPTIONS_FILE_UNSET+=SDK OPTIONS_FILE_UNSET+=SYSTRAY OPTIONS_FILE_UNSET+=TEST OPTIONS_FILE_SET+=WEBDAV
I can reproduce it by enabling QT5 option.
Which revision of -CURRENT? Is that after base r351253?
I'm on 12.0-RELEASE-p8 and facing the same issue, the build is broken with editors_libreoffice_UNSET+= GTK2 GTK3 editors_libreoffice_SET+= JAVA KDE5 SYSTRAY WEBDAV (probably caused by KDE5 option)
(In reply to Felix Palmen from comment #10) > (probably caused by KDE5 option) KDE5_IMPLIES= QT5
Created attachment 206765 [details] removing using of std::function I haven't tried with base r351253, but this one looks like "Class template argument deduction for aggregates" feature, ref: https://clang.llvm.org/cxx_status.html https://bugs.llvm.org/show_bug.cgi?id=39606 Please try the attached workaround.
Created attachment 206773 [details] removing using of std::function from vcl/unx/kde5/KDE5SalInstance.cxx (In reply to Li-Wen Hsu from comment #12) vcl/unx/kde5/KDE5SalInstance.cxx need the same patch.
The same is on FreeBSD-11 STABLE
(In reply to gja822 from comment #14) amd64
Compiled fine with our patches on 12.0 i386: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=206765 https://bugs.freebsd.org/bugzilla/attachment.cgi?id=206773
A commit references this bug: Author: lwhsu Date: Thu Aug 22 06:21:32 UTC 2019 New revision: 509581 URL: https://svnweb.freebsd.org/changeset/ports/509581 Log: Workaround for build failure due to newer C++ features when KDE5 and QT5 defined PR: 239988 Submitted by: VVD <vvd@unislabs.com> Reported by: O. Hartmann <ohartmann@walstatt.org> Changes: head/editors/libreoffice/files/patch-vcl_qt5_Qt5Instance.cxx head/editors/libreoffice/files/patch-vcl_unx_kde5_kde5salinstance.cxx
The latest commit fixes the build for my configuration, thanks!
Please report this upstream (with the same fix; I've asked them to look at it already). It's a valid change, simplifies the code a bit.
(In reply to Adriaan de Groot from comment #19) I'm still wondering and testing if my assumption in #12 is correct, I am not sure the feature used here is c++17 or c++2a. Also from the https://clang.llvm.org/cxx_status.html It seems that there are some features supported since clang7 and in current compiler.mk, it still uses clang6 for c++17.
(In reply to Adriaan de Groot from comment #19) > Please report this upstream (with the same fix; I've asked them to look at it already). It's a valid change, simplifies the code a bit. https://bugs.documentfoundation.org/show_bug.cgi?id=127408
It was fixed upstream.
MARKED AS SPAM