Created attachment 101808 [details] moc_slaveinterface.cpp file generated by Qt 5.7.0 automoc Centos 6.8 32 bits GCC : gcc (GCC) 4.9.1 20140922 (Red Hat 4.9.1-10) Qt : 5.7.0 Cmake : cmake3 version 3.6.1 KF5 : 5.27 or git/master [ 5%] Building CXX object src/core/CMakeFiles/KF5KIOCore.dir/slaveinterface.cpp.o In file included from /home/gilles/devel/kio/src/core/slaveinterface.cpp:437:0: /home/gilles/devel/kio/build/src/core/moc_slaveinterface.cpp: In static member function ‘static void KIO::SlaveInterface::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)’: /home/gilles/devel/kio/build/src/core/moc_slaveinterface.cpp:165:22: error: ‘class KIO::SlaveInterface’ has no member named ‘open64’ case 10: _t->open64(); break; ^ /home/gilles/devel/kio/build/src/core/moc_slaveinterface.cpp:274:67: error: ‘open64’ is not a member of ‘KIO::SlaveInterface’ if (*reinterpret_cast<_t *>(func) == static_cast<_t>(&SlaveInterface::open64)) { ^ In file included from /home/gilles/devel/kio/src/core/slaveinterface.cpp:437:0: /home/gilles/devel/kio/build/src/core/moc_slaveinterface.cpp: At global scope: /home/gilles/devel/kio/build/src/core/moc_slaveinterface.cpp:462:34: error: no ‘void KIO::SlaveInterface::open64()’ member function declared in class ‘KIO::SlaveInterface’ void KIO::SlaveInterface::open64() ^ make[2]: *** [src/core/CMakeFiles/KF5KIOCore.dir/slaveinterface.cpp.o] Error 1 make[1]: *** [src/core/CMakeFiles/KF5KIOCore.dir/all] Error 2 make: *** [all] Error 2 Note : All the rest compile fine on Centos 6.8 32 bits, as : - Qt5 - kconfig - breeze-icons - solid - kcoreaddons - kwindowsystem - solid - threadweaver - karchive - kdbusaddons - ki18n - kcrash - kcodecs - kauth - kguiaddons - kwidgetsaddons - kitemviews - kcompletion - kconfigwidgets - kiconthemes - kservice - kglobalaccel - kxmlgui - kbookmarks - kimageformats - kjobwidgets - sonnet - ktextwidgets
Created attachment 101813 [details] proof of concept to solve temporally the problem The problem come from signal named open() which sound miss interpreted by automoc and renamed as open64(), certainly to prevent conflict with system fonctions or something like that. Renaming the signal as signalOpen() fix the compilation problem, but of course this cannot be a real solution...
Note : With KIO test code, another signal break the compilation : [ 59%] Automatic moc for target jobtest [ 59%] Built target jobtest_automoc [ 59%] Building CXX object autotests/CMakeFiles/jobtest.dir/jobtest_automoc.cpp.o In file included from /home/gilles/devel/kio/build/autotests/jobtest_automoc.cpp:2:0: /home/gilles/devel/kio/build/autotests/moc_jobtest.cpp: In static member function ‘static void JobTest::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)’: /home/gilles/devel/kio/build/autotests/moc_jobtest.cpp:353:22: error: ‘class JobTest’ has no member named ‘stat64’ case 40: _t->stat64(); break; ^ make[2]: *** [autotests/CMakeFiles/jobtest.dir/jobtest_automoc.cpp.o] Error 1 make[1]: *** [autotests/CMakeFiles/jobtest.dir/all] Error 2 make: *** [all] Error 2
Would it be enough to #undef open in that header file? (and #undef stat in the test file) #defines are EVIL btw...
I will test quickly. I'm surprised to see this problem only in KIO frameworks. To bunble as AppImage, we need CentoS 6, and i recompiled 80% of KF5 and it's the only place where this kind of problem appear... Gilles Caulier
Created attachment 101889 [details] new patch based on #undef Confirmed. #undef work as expected. All KIO compile fine now. Patch updated.
Comment on attachment 101889 [details] new patch based on #undef Thanks. Can you try something else? If you remove #include <qplatformdefs.h> from slaveinterface.h, does that fix the error in slaveinterface.h ? This include isn't necessary and seems to bring in what is causing the problem.
(which would explain why it only happens there -- mostly only KIO code uses qplatformdefs.h)
ok, i try this patch while this morning. Gilles Caulier
No, commenting qplatformdef.h include in slaveinterface.h do not fix the problem. Gilles Caulier
Note that it wouldn't fix both instances, only the one in moc_slaveinterface.cpp. You must have a #define open open64 somewhere in a system header. Any chance you could use gcc -E or grep -r to find out where this happens? IMHO that's a bug in that system header. I'm not fully opposed to committing a workaround, but it's still good to find the heart of the issue as well.
As explained before, this only happen under 32 Centos 6.8, not 64 bits version. Centos is used to create 32 bits and 64 bits AppImage bundles for my office. Typically, Kate and QtCreator (and more KF5 applications later) are used to develop real time acquisition codes on an experimental Tokamak. We use Centos 6, for legacy reasons, to be compatible with hardwares. And we want to use a modern code editor as Kate, especially in 32 bits, instead official GEdit under Centos 6, which is just a dinosaur. So, as i need to compile whole Qt5/KF5 with a C++11 compatible compiler, i need a more recent version of GCC under Centos 6. With a 64 bits system, we have plenty of repos with different versions of GCC, supported by Centos 6. With a 32 bits system, nothing. I need to use CERN Centos repo where a GCC is available. This can explain the difference between 32 and 64 bits, even if GCC version is the same for both. Gilles Caulier
[gilles@localhost kio]$ pwd /home/gilles/devel/kio [gilles@localhost kio]$ ls autotests CMakeCache.txt cmake_install.cmake COPYING.LIB docs KF5KIOConfig.cmake KF5KIOConfigVersion.cmake metainfo.yaml src cmake CMakeFiles CMakeLists.txt CTestTestfile.cmake ecm_uninstall.cmake KF5KIOConfig.cmake.in Makefile README.md tests [gilles@localhost kio]$ grep -r open64 src/core/CMakeFiles/KF5KIOCore.dir/slaveinterface.cpp.o:extern FILE *fopen (__const char *__restrict __filename, __const char *__restrict __modes) __asm__ ("" "fopen64") src/core/CMakeFiles/KF5KIOCore.dir/slaveinterface.cpp.o:extern FILE *freopen (__const char *__restrict __filename, __const char *__restrict __modes, FILE *__restrict __stream) __asm__ ("" "freopen64") src/core/CMakeFiles/KF5KIOCore.dir/slaveinterface.cpp.o:extern FILE *fopen64 (__const char *__restrict __filename, src/core/CMakeFiles/KF5KIOCore.dir/slaveinterface.cpp.o:extern FILE *freopen64 (__const char *__restrict __filename, src/core/CMakeFiles/KF5KIOCore.dir/slaveinterface.cpp.o:extern int open (__const char *__file, int __oflag, ...) __asm__ ("" "open64") src/core/CMakeFiles/KF5KIOCore.dir/slaveinterface.cpp.o:extern int open64 (__const char *__file, int __oflag, ...) __attribute__ ((__nonnull__ (1))); src/core/CMakeFiles/KF5KIOCore.dir/slaveinterface.cpp.o: "KIO::filesize_t\0open64\0written\0metaData\0" src/core/CMakeFiles/KF5KIOCore.dir/slaveinterface.cpp.o: case 10: _t->open64(); break; src/core/CMakeFiles/KF5KIOCore.dir/slaveinterface.cpp.o: if (*reinterpret_cast<_t *>(func) == static_cast<_t>(&SlaveInterface::open64)) { src/core/CMakeFiles/KF5KIOCore.dir/slaveinterface.cpp.o:void KIO::SlaveInterface::open64() src/core/moc_slaveinterface.cpp:QT_MOC_LITERAL(15, 166, 6), // "open64" src/core/moc_slaveinterface.cpp: "KIO::filesize_t\0open64\0written\0metaData\0" src/core/moc_slaveinterface.cpp: case 10: _t->open64(); break; src/core/moc_slaveinterface.cpp: if (*reinterpret_cast<_t *>(func) == static_cast<_t>(&SlaveInterface::open64)) { src/core/moc_slaveinterface.cpp:void KIO::SlaveInterface::open64() [gilles@localhost kio]$
The last two comments do no add any information :-) The #define comes from a system header, as I said, not from KIO's own sources. Actually, I can grep the internet instead... Yep: http://ac-archive.sourceforge.net/largefile/glibc.html https://git.busybox.net/uClibc/plain/include/fcntl.h both have "#define open open64", as I suspected. Horrible! But it's probably old news, since this hack was only for largefile support on 32 bit systems, so no "upstream" fix possible at this point. I'll push the #undef fix (into KF 5.28).
Wait. Something is really broken on CentOS 6.8 though, because according to http://ac-archive.sourceforge.net/largefile/glibc.html the #define open open64 should only happen when __REDIRECT is not set, and it should be set for gcc >= 2.x, see cdefs.h on that page. Can you check if your system headers match what that page says? I'm not pushing the #undef hacks after all, they shouldn't be needed.
You is right. The system header do not match the __REDIRECT condition at all. IU suspect that the RH package devtoolset-3 provided by CERN for Scientific Linux is broken or something like that. I plan to use cross compilation under CentoOS 64 to build 32 bits version of AppImage bundle. Feel free to close this file. Gilles Caulier
I just reproduced this issue while building ARM32 binaries on Flatpak. This is a bug related to both our bigger upstreams... https://bugreports.qt.io/browse/QTBUG-57796 https://gitlab.kitware.com/cmake/cmake/issues/16640
Reopening because this requires changes in cmake that won't be backported. Bug report in upstream cmake: https://gitlab.kitware.com/cmake/cmake/issues/16640 Will see into offering a workaround meanwhile.
Upstream patch... https://gitlab.kitware.com/cmake/cmake/merge_requests/671
Git commit 781cfa4e2ba739ee864683a3c783572852f43984 by Aleix Pol. Committed on 06/04/2017 at 17:23. Pushed by apol into branch 'master'. Generate a moc_predefs.h file for KIOCore Summary: Otherwise moc gets through wrong files in some platforms that have weird preprocessor hacks to support large files on 32 bits systems. This should be done by automoc. See: https://gitlab.kitware.com/cmake/cmake/issues/16640 https://bugreports.qt.io/browse/QTBUG-57796 Test Plan: Fixes build of KIO on ARM32 (flatpak) Reviewers: #frameworks, dfaure, cgilles Reviewed By: dfaure Subscribers: #frameworks Tags: #frameworks Differential Revision: https://phabricator.kde.org/D5319 M +4 -0 autotests/CMakeLists.txt M +10 -0 src/core/CMakeLists.txt https://commits.kde.org/kio/781cfa4e2ba739ee864683a3c783572852f43984