Bug 439780 - kio does not compile with libc++ due to the use of the (obsolete and removed) std::mem_fun
Summary: kio does not compile with libc++ due to the use of the (obsolete and removed)...
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.84.0
Platform: Gentoo Packages Linux
: NOR major
Target Milestone: ---
Assignee: KIO Bugs
Depends on:
Reported: 2021-07-12 10:22 UTC by Manuel Nickschas
Modified: 2021-07-19 13:37 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Manuel Nickschas 2021-07-12 10:22:27 UTC

Kio 5.84.0 does not compile with libc++, causing the following error:

FAILED: src/widgets/CMakeFiles/KF5KIOWidgets.dir/kpropertiesdialog.cpp.o 
WARNINGS_SINCE=0x0 -DKIOCORE_DISABLE_DEPRECATED_BEFORE_AND_AT=0x0 -DKIOWIDGETS_DEPRECATED_WARNINGS_SINCE=0x0 -DKIOWIDGETS_DISABLE_DEPRECATED_BEFORE_AND_AT=0x0 -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DEPRECATED_WARNINGS_SINCE=0x060000 -DQT_DISABLE_DEPRECATED_BEFORE=0x050f00 -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_FROM_BYTEARRAY -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_FOREACH -DQT_NO_KEYWORDS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_URL_CAST_FROM_STRING -DQT_STRICT_ITERATORS -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_XML_LIB -DTRANSLATION_DOMAIN=\"kio5\" -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -Isrc/widgets -I/var/tmp/portage/kde-frameworks/kio-5.84.0/work/kio-5.84.0/src/widgets -Isrc/widgets/KF5KIOWidgets_autogen/include -Isrc/gui -I/var/tmp/portage/kde-frameworks/kio-5.84.0/work/kio-5.84.0/src/gui -Isrc/core/.. -I/var/tmp/portage/kde-frameworks/kio-5.84.0/work/kio-5.84.0/src/core/kssl -Isrc/core -I/var/tmp/portage/kde-frameworks/kio-5.84.0/work/kio-5.84.0/src/core -isystem /usr/include/KF5/KCoreAddons -isystem /usr/include/KF5 -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/mkspecs/linux-clang -isystem /usr/include/KF5/KService -isystem /usr/include/KF5/KConfigCore -isystem /usr/include/qt5/QtNetwork -isystem /usr/include/qt5/QtDBus -isystem /usr/include/KF5/KWindowSystem -isystem /usr/include/qt5/QtGui -isystem /usr/include/KF5/KJobWidgets -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/KF5/Solid -isystem /usr/include/KF5/KCompletion -isystem /usr/include/KF5/KWidgetsAddons -isystem /usr/include/qt5/QtConcurrent -isystem /usr/include/KF5/KI18n -isystem /usr/include/KF5/KGuiAddons -isystem /usr/include/KF5/KIconThemes -isystem /usr/include/KF5/KConfigWidgets -isystem /usr/include/KF5/KCodecs -isystem /usr/include/KF5/KConfigGui -isystem /usr/include/qt5/QtXml -isystem /usr/include/KF5/KAuth  -DQT_NO_DEBUG -O3 -march=native -pipe -fomit-frame-pointer -fno-operator-names -fno-exceptions -Wno-gnu-zero-variadic-macro-arguments -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -fdiagnostics-color=always -pedantic -Wzero-as-null-pointer-constant -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -std=c++17 -MD -MT src/widgets/CMakeFiles/KF5KIOWidgets.dir/kpropertiesdialog.cpp.o -MF src/widgets/CMakeFiles/KF5KIOWidgets.dir/kpropertiesdialog.cpp.o.d -o src/widgets/CMakeFiles/KF5KIOWidgets.dir/kpropertiesdialog.cpp.o -c /var/tmp/portage/kde-frameworks/kio-5.84.0/work/kio-5.84.0/src/widgets/kpropertiesdialog.cpp
/var/tmp/portage/kde-frameworks/kio-5.84.0/work/kio-5.84.0/src/widgets/kpropertiesdialog.cpp:2275:74: error: no member named 'mem_fun' in namespace 'std'; did you mean 'mem_fn'?
        std::for_each(theNotSpecials.begin(), theNotSpecials.end(), std::mem_fun(&QWidget::hide));
/usr/include/c++/v1/functional:1410:1: note: 'mem_fn' declared here
mem_fn(_Rp _Tp::* __pm) _NOEXCEPT
1 error generated.

std::mem_fun was deprecated in C++11 in favor of std::mem_fn and finally removed in C++17, so while it still may be around in GCC/stdlibc++ even with -std=c++17, it must no longer be used and cannot be expected to compile with other toolchains.

This issue was newly introduced in 5.84.0, at least previous versions compiled with no issues.

1. Compile with libc++ (Clang or GCC does not matter)


Does not compile with libc++ due to use of std::mem_fun which was removed from C++17


Should compile with any standards-compliant toolchain

KDE Frameworks Version: 5.84.0
Comment 1 Bug Janitor Service 2021-07-12 14:22:58 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/496
Comment 2 Jan Paul Batrina 2021-07-12 14:35:29 UTC
Git commit 36f1814b184f4d5ac628fca5db5f6cc1440b4db7 by Jan Paul Batrina.
Committed on 12/07/2021 at 14:06.
Pushed by ahmadsamir into branch 'master'.

Use std::mem_fn instead of the deprecated/removed std::mem_fun

std::mem_fun was deprecated in C++11 and removed from
the standard in C++17.

M  +1    -1    src/widgets/kpropertiesdialog.cpp

Comment 3 Manuel Nickschas 2021-07-12 15:12:09 UTC
Thanks, this fixes the issue for me! I wasn't completely sure if it can just be replaced, thus I didn't offer a patch myself.

Kudos for the quick reaction!
Comment 4 Ahmad Samir 2021-07-12 17:38:12 UTC
Thanks for the report :)

I tested building with clang and it built without this patch, also IIUC FreeBSD uses clang and libc++ by default and those builds passed on the KDE Jenkins CI instance without this patch. So I don't know why it failed to build for you. Could be extra compiler flags?

Anyway, it's good to port to std::mem_fn.
Comment 5 Ahmad Samir 2021-07-12 17:41:34 UTC
It seems I need to add -stdlib=libc++ to the compiler flags for clang to use libc++, I'll test that next :)
Comment 6 Manuel Nickschas 2021-07-19 13:25:47 UTC
(In reply to Ahmad Samir from comment #5)
> It seems I need to add -stdlib=libc++ to the compiler flags for clang to use
> libc++, I'll test that next :)

Yes, you either need to configure Clang to use libc++ by default, or you need to explicitly specify that compiler flag.

Note that mixing libc++ and libstdc++ in your system C++ libraries may cause problems (due to ABI incompatibilities), so if you want to have a CI system set up for testing the Clang/libc++ combination, it probably should be based on a system fully built with libc++.
Comment 7 Ahmad Samir 2021-07-19 13:37:12 UTC
Yeah, I found that out myself, the build failed with very weird errors indeed :)

I'd have to build the whole stack, which isn't simple. Good thing the fix is obvious enough it didn't require that (or we could have asked our FreeBSD devs to test, since they use clang/libc++ by default IIUC).