Failure to find SIP on macOS

When testing ROS 2 Galactic (actually rolling since we haven't forked yet) on macOS Mojave, packages downstream of python_qt_binding fail to find SIP like this:

Starting >>> qt_gui_cpp
--- stderr: qt_gui_cpp                                                          
CMake Warning at /Users/william/ros2_rolling/install/python_qt_binding/share/python_qt_binding/cmake/sip_helper.cmake:27 (message):
  SIP binding generator NOT available.
Call Stack (most recent call first):
  src/qt_gui_cpp_sip/CMakeLists.txt:56 (include)


CMake Error at src/CMakeLists.txt:10 (message):
  No Python binding generator found.


---
Failed   <<< qt_gui_cpp [2.72s, exited with code 1]

This is the version of SIP that is installed by default (as of writing) on a fresh macOS machine:

macos-10:ros2_rolling william$ brew info sip
sip: stable 6.0.3 (bottled), HEAD
Tool to create Python bindings for C and C++ libraries
https://www.riverbankcomputing.com/software/sip/intro
/usr/local/Cellar/sip/6.0.3_1 (708 files, 10.7MB) *
  Poured from bottle on 2021-04-14 at 16:26:19
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/sip.rb
License: GPL-2.0-only or GPL-3.0-only
==> Dependencies
Required: python@3.9 ✔
==> Options
--HEAD
	Install HEAD version
==> Analytics
install: 31,588 (30 days), 79,774 (90 days), 258,068 (365 days)
install-on-request: 7,641 (30 days), 12,754 (90 days), 32,176 (365 days)
build-error: 0 (30 days)
macos-10:ros2_rolling william$ brew search sip
==> Formulae
baresip    libexosip  libosip    sip ✔      sipcalc    sipp       sipsak     sofia-sip
==> Casks
homebrew/cask/sip

I'm not sure if it is because we just need something like #94 to be merged, or if SIP>=6 is supposed to be used with Qt 6 (we're still using Qt 5 as qt@5 on macOS, but there's no equivalent for sip that I can find in homebrew).

Hi. I just found this out as well. The problem is that sipconfig was removed after SIP 4. So the

COMMAND ${PYTHON_EXECUTABLE} -c "import sipconfig; print(sipconfig.Configuration().sip_bin)"

in /python_qt_binding/cmake/sip_helper.cmake fails. However, PyQt and all bindings are already installed when I install it via brew and sip also works. To make rolling build, I removed the error in ros-visualization/qt_gui_core/qt_gui_cpp/src/CMakeLists.txt:

message(STATUS "Python binding generators: ${qt_gui_cpp_BINDINGS}")
if(NOT qt_gui_cpp_BINDINGS)
  # message(FATAL_ERROR "No Python binding generator found.")
endif()

After that everything is building and my code works as well as qt-applications (both cpp and py qt-applications). I compiled it on Big Sur.

Is it necessary to actually generate the bindings when building ROS? If it is necessary, the code needs to be migrated to use the newer versions of SIP, i think.

Is it necessary to actually generate the bindings when building ROS? If it is necessary, the code needs to be migrated to use the newer versions of SIP, i think.

It's a good question. Most of the RQt tools are written in Python/PyQt already, so they don't really need the SIP stuff. A quick look around seems to say that we don't actually use the SIP rqt stuff (at least, none of the package.xml files seem to depend on it).

So one way out of this may be to just remove the qt_gui_cpp stuff completely.

Hey everyone, according to Riverbank Computing version 4 is unsupported, however they provide tar and zip files with version 4.19.25. I've attempted to install ROS Galactic on Big Sur and have been unsuccessful in getting qt_gui_cpp with SIP 4.19.25 to install for another reason:

CMake Error at /usr/local/Cellar/cmake/3.19.4/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:218 (message):
  Could NOT find PythonLibs (missing: PYTHON_LIBRARIES PYTHON_INCLUDE_DIRS)
  (Required is at least version "3.9")
Call Stack (most recent call first):
  /usr/local/Cellar/cmake/3.19.4/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:582 (_FPHSA_FAILURE_MESSAGE)
  /usr/local/Cellar/cmake/3.19.4/share/cmake/Modules/FindPythonLibs.cmake:310 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  src/qt_gui_cpp/CMakeLists.txt:2 (find_package)

If I come up for a solution to this other python problem then I think maybe we'll need to wrap versions of SIP and other Qt versions within the osrf brew tap.

EDIT: This was an issue with Xcode command line tools not installed and reinstalling Python through brew again.

@clalancette

I think that either the possibility for c++ plugins in rqt is removed or that the code is updated to SIP 6. Maybe as @clalancette suggested, this is not really used and could be removed. There have always been a lot of issues with this on mac.

Another work around maybe to use PySide instead of PyQt? I'm not sure about the feasibility of it but I know RViz allows for both.

@clalancette

I just came across this problem.
In my case I'm using Linux, but I'm installing Python packages via pip rather than via apt-get in order to use them in a virtual environment.

Running apt-get install python3-sip installs version 4.19.7 (which includes sipconfig) on the other hand pip3 install sip installs version 6 which does not include sipconfig.
Similarly it looks like sipconfig is not present also in older versions distributed by pip, e.g. I got same error also using pip3 install sip==4.19.7.

Following @clalancette suggestion, I resolved the problem by simply ignoring the qt_gui_cpp and rqt_gui_cpp packages during the build.

@alsora

@alsora Can you please elaborate on how to ignore those packages?

@omerts

@omerts
Just add a file named COLCON_IGNORE into the qt_gui_cpp and rqt_gui_cpp folders...
Or just remove them alltogether from your workspace

A quick look around seems to say that we don't actually use the SIP rqt stuff

The Python bindings are still used in a few of the rqt plugins. The pyside / shiboken bindings do work on macOS, and if the sip bindings are excluded then python_qt_binding and its dependent packages will build and run.

I've made a couple of non-portable patches to illustrate the changes. brew installs pyside@2 and qt@5 as keg only and I've hardcoded the paths to these in find_package to get up and running.

python_qt_binding 10b101a
qt_gui_core ros-visualization/qt_gui_core@162600b

Ensure pyside@2 is in the PYTHONPATH before running rqt:

export PYTHONPATH=$PYTHONPATH:/usr/local/opt/pyside@2/lib/python3.10/site-packages

Here is ROS2 Humble running rqt on macOS Monterey (intel MacPro).

Edit: 2 Sep 2022

Updated link to commit for python_qt_binding patch.

@srmainwaring

@srmainwaring If you find a way to clean up those patches, we'd be happy to review them.

Additionally, @ipa-cmh has started working in this area to try to rectify all of the different ways we use Python with Qt. See #115 , ros2/rviz#889 , and #114 .

@clalancette

@clalancette I've cleaned up the patches and submitted these PRs:

There is an ugly macOS specific work-around for the shiboken generator's include dependency on some Qt components. Depending on the plans / timelines you mention above to streamline the approaches to use Qt Python this may or may not be acceptable as an interim measure.

I'm also running into this on Ubuntu 23.04 (Lunar). Yes, I know it's not a supported distro, but I thought I could at least make people aware.

Temporary solution:
colcon build --packages-skip qt_gui_cpp --packages-skip-by-dep qt_gui_cpp

Looks like QT5 just went EOL anyways.
https://en.wikipedia.org/wiki/Qt_version_history

Any progress on this (for macOS)?

I get this problem on Ubuntu22.04 Server as well

I get this problem on Ubuntu22.04 Server as well

Maybe try this step

cd ros-visualization
sudo rosdep init
rosdep update
rosdep install --from-paths . --ignore-src -r -y
cd .. && colcon build --packages-select qt_gui_cpp

in my compute, build qt_gui_cpp finished

Navigation Menu

Repository navigation

Failure to find SIP on macOS #103

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Failure to find SIP on macOS #103

Description

Activity

kristoferB commented on Apr 29, 2021

clalancette commented on Apr 29, 2021

zmk5 commented on May 6, 2021

kristoferB commented on May 6, 2021

zmk5 commented on May 7, 2021

alsora commented on May 13, 2021

omerts commented on Feb 15, 2022

alsora commented on Feb 15, 2022

srmainwaring commented on Aug 30, 2022

clalancette commented on Aug 30, 2022

srmainwaring commented on Sep 2, 2022

Ryanf55 commented on Jun 25, 2023

JetForMe commented on Sep 24, 2023

Kaju-Bubanja commented on Jan 30, 2025

paulliu617 commented on Mar 20, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions