qt_gui_cpp compiler errors wrt QBasicAtomicInt on macOS

[Napoleon-BlownApart]

[MacOS, Mojave 10.14.5, Xcode 10.2 & Clang 9 (homebrew), Qt5.14.1]

I'm following the kinetic Installation OSX Homebrew Source guide, which has some hick-ups. I'm fixing each problem as it comes along, and I'm up to the qt_gui_cpp package where I've encountered a problem which I'm not sure how to approach.

The compiler is telling me that there are significant errors in the Qt package, which I find hard to believe. I think there's something missing but I don't yet know what. The first error is telling me that that there is no member called loadRelaxed() in QBasicAtomicInt.

However, atomic is defined as a QBasicAtomicInt, which itself is defined as typedef QBasicAtomicInteger<Int>. QBasicAtomicInteger does have a loadRelaxed() method, so why can't the QBasicAtomicInteger functor be accessed? Should there be a static_cast<QBasicAtomicInteger<Int>> of atomic in the header file Headers/qrefcount.h (Line55)?

Initially I thought this may have something to do with Shiboken's wrappers, but now that I have Shiboken2 working (never mind the odd looking path in the log below), my errors seem to occur for other reasons.

The build is flagging other errors in the Qt 5.14.1 header files, such as QObject being an incomplete type, undeclared udentifier d_ptr, no template named List did you mean QList, and others?

It appears that I have two conflicting sets of Qt headers. I have Qt v4.8.7_6 installed (brew linked) into /usr/local/include, and Qt v5.14.1 (keg) installed into /usr/local/opt/qt (which points to (/usr/local/Cellar/qt/5.14.1/lib/QtCore.framework/Headers). I have been using the newer version obviously for this build.

I tried, by adjusting in the qt_gui_cpp package's CMakeLists.txt file, using:
1 set(CMAKE_IGNORE_PATH /usr/local/include)
2 set(LDFLAGS -L/usr/local/opt/qt/lib) and set(CPPFLAGS -I/usr/local/opt/qt/include)
3 I tried using target_include_directories(${PROJECT_NAME} SYSTEM BEFORE PUBLIC ${qt_gui_cpp_INCLUDE_DIRECTORIES}) to prepend the includes, but as you can see below, they ended up after the -I/usr/local/include anyway.

But neither have helped. (Even though the compiler error gives the correct path to the v5.14.1 header files, I think it's actually using the wrong version under the hood.)

The actual compiler command that is issued is below. Note that -I/usr/local/include precedes the Qt v5.14.1 include, thus the compiler only looks into the Qt v5.14.1 folder when it can't find it under /usr/local/include.

So, the question now is, how can I remove `/usr/local/include/?

    [ 22%] Building CXX object src/qt_gui_cpp/CMakeFiles/qt_gui_cpp.dir/composite_plugin_provider.cpp.o
    cd /Users/user/ros/ros_catkin_ws/build_isolated/qt_gui_cpp/src/qt_gui_cpp && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
    -DQT_CORE_LIB
    -DQT_GUI_LIB
    -DQT_NO_DEBUG
    -DQT_WIDGETS_LIB
    -DROS_BUILD_SHARED_LIBS=1
    -DROS_PACKAGE_NAME=\"qt_gui_cpp\"
    -Dqt_gui_cpp_EXPORTS
    -I/Users/user/ros/ros_catkin_ws/src/qt_gui_core/qt_gui_cpp/include
    -I/Users/user/ros/ros_catkin_ws/install_isolated/include
    -I/usr/local/include
    -I/Users/user/ros/ros_catkin_ws/src/qt_gui_core/qt_gui_cpp/src/qt_gui_cpp/qt_gui_cpp
    -isystem /usr/local/Cellar/qt/5.14.1/lib/QtCore.framework/Headers
    -isystem /usr/local/Cellar/python@2/2.7.17_1/Frameworks/Python.framework/Versions/2.7/include/python2.7
    -isystem /Users/user/ros/ros_catkin_ws/src/qt_gui_core/qt_gui_cpp/include/qt_gui_cpp
    -isystem /Users/user/ros/ros_catkin_ws/src/qt_gui_core/qt_gui_cpp/src/qt_gui_cpp
    -iframework /usr/local/Cellar/qt/5.14.1/lib
    -isystem /usr/local/Cellar/qt/5.14.1/lib/QtWidgets.framework/Headers
    -isystem /usr/local/Cellar/qt/5.14.1/lib/QtGui.framework/Headers
    -isystem /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks/OpenGL.framework/Headers
    -isystem /usr/local/Cellar/qt/5.14.1/./mkspecs/macx-clang
    -I/usr/local/opt/qt/include
    -L/usr/local/opt/qt/lib
    -fPIC
    -O3
    -DNDEBUG
    -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
    -fPIC
    -fPIC
    -std=gnu++11
    -o CMakeFiles/qt_gui_cpp.dir/composite_plugin_provider.cpp.o
    -c /Users/user/ros/ros_catkin_ws/src/qt_gui_core/qt_gui_cpp/src/qt_gui_cpp/composite_plugin_provider.cpp

(If any further info needed, let me know.)

Thanks in advance.
(I've been able to build all the preceding packages, including OpenCV3 and python_qt_binding successfully.)

loadRelaxed() error:

[ 61%] Building CXX object src/qt_gui_cpp/CMakeFiles/qt_gui_cpp.dir/settings.cpp.o
In file included from /Users/user/ros/ros_catkin_ws/src/qt_gui_core/qt_gui_cpp/src/qt_gui_cpp/recursive_plugin_provider.cpp:33:
In file included from /Users/user/ros/ros_catkin_ws/src/qt_gui_core/qt_gui_cpp/include/qt_gui_cpp/recursive_plugin_provider.h:36:
In file included from /Users/user/ros/ros_catkin_ws/src/qt_gui_core/qt_gui_cpp/include/qt_gui_cpp/composite_plugin_provider.h:36:
In file included from /Users/user/ros/ros_catkin_ws/src/qt_gui_core/qt_gui_cpp/include/qt_gui_cpp/plugin_descriptor.h:36:
In file included from /usr/local/Cellar/qt/5.14.1/lib/QtCore.framework/Headers/QMap:1:
In file included from /usr/local/Cellar/qt/5.14.1/lib/QtCore.framework/Headers/qmap.h:45:
/usr/local/Cellar/qt/5.14.1/lib/QtCore.framework/Headers/qrefcount.h:55:28: error: no member named 'loadRelaxed' in 'QBasicAtomicInt'
        int count = atomic.loadRelaxed();
                    ~~~~~~ ^

[jcvtieck]

Hi, I'm having the same error building melodic under osx catalina.

In file included from /usr/local/opt/qt/lib/QtCore.framework/Headers/qmap.h:45:
/usr/local/opt/qt/lib/QtCore.framework/Headers/qrefcount.h:55:28: error: no member named
      'loadRelaxed' in 'QBasicAtomicInt'
        int count = atomic.loadRelaxed()

to reproduce the error:

cd ~/ros_catkin_ws/build_isolated/qt_gui_cpp && ~/ros_catkin_ws/install_isolated/env.sh make -j8 -l8

[rotu]

I think Mac build problems are related to this #212 since XCode uses recent Clang versions

[dirk-thomas]

Please consider to propose a pull request to address this problem.

[rotu]

Please consider to propose a pull request to address this problem.

I don't know if this was addressed to me, but I don't expect to be able to work on this. It seems like the package maintainer's responsibility.

[dirk-thomas]

I don't know if this was addressed to me, but I don't expect to be able to work on this.

It wasn't addressed to you specifically - it was addressed to anyone on this thread as well as any future reader.

It seems like the package maintainer's responsibility.

What you are basically saying is that it isn't important enough for you to spend your time on it but you expect that it is important enough that you "demand" that someone should spend their time on it and fix the problem for you. That kind of expectation is unfortunately an unrealistic one.

While a maintainer would probably prefer to be able to fix all issues and satisfy all incoming feature idea that is something which doesn't scale. A large open source project like ROS depends on contributors to help and not expect a few people to do all the work.

[Napoleon-BlownApart]

@dirk-thomas I fully understand your reasoning and appreciate the effort being contributed by many so I can achieve my personal goals. Having said that, when my circumstances change, I will be glad to help push this further. I am presently unable to progress this further due to time pressures with my studies and my immediate need was satisfied via in install onto my Raspberry Pi4.

Where I got up to before I ran out of time was a successful build of the same QT version included via the ROS packages but using the distribution from the QT site. The logic here was that if I could build QT but the above error didn't go away, then the error was on the ROS side of things. I will return to this when I have time.

[rotu]

What you are basically saying is that it isn't important enough for you to spend your time on it but you expect that it is important enough that you "demand" that someone should spend their time on it and fix the problem for you. That kind of expectation is unfortunately an unrealistic one.

While a maintainer would probably prefer to be able to fix all issues and satisfy all incoming feature idea that is something which doesn't scale. A large open source project like ROS depends on contributors to help and not expect a few people to do all the work.

I don't demand anything, and I'm sorry if you took at as that. But I am specifically avoiding being the point person for this bug.

My understanding is that "maintainer" is a point person who is generally responsible for making sure bugs get fixed and that PRS get triage. At the very minimum, this means making sure it builds. If that's you, since your name is in the package.xml, then please fix it. If there is no such person, the package should be marked as orphaned, as per REP-149. If "maintainer" means something else, the REP should be updated.

[dirk-thomas]

At the very minimum, this means making sure it builds. If that's you, since your name is in the package.xml, then please fix it.

The package does build successfully on the ROS CI infrastructure. So I assume the environment where it fails is somehow different. That is why I rely on contributors to provide the necessary patches.

I don't demand anything
...
If that's you, since your name is in the package.xml, then please fix it.

🤐

[rotu]

I don't demand anything
...
If that's you, since your name is in the package.xml, then please fix it.

🤐

Yes, that’s a request, not a demand. You are a maintainer, and I think that’s a reasonable expectation of the role.

[rotu]

The package does build successfully on the ROS CI infrastructure.

I don't know how to confirm this. The only automated CI I see for PRs in this repo is Linux, and it doesn't look like the full battery of builds is run manually for each PR.

The linux_clang_libcxx nightly build uses Clang 10.0.0, but the whole build is currently broken.

Mojave, a REP 2000 target platform, supports both XCode 10 and XCode 11. I'm not sure which Mac build you're referring to, or which version of Clang this is equivalent to.

So this might not be broken on a REP 2000 target platform - I'm unclear about which compilers are targeted.