qt_gui_cpp fails to build on debian Jessie

[boris-il-forte]

I ask here because on the ros answers website I haven't got any response.

I'm triyng to build qt_gui_cpp on debian jessie. The last time I've tried I've got the same issue:

when running the compilation, shiboken crashes (Segmentation Fault), thus i'm unable to compile correctly the code.

Last time i've solved updating shiboken, but this time I've the same version of shiboken as the ubuntu one.

here there is the link of the question on ros answer where I've post the crash log:
http://answers.ros.org/question/99351/qt_gui_cpp-fails-to-build-on-debian-jessie/

also I've searched precisely where the crash happens, and it happens when make invoke the command:

cd /home/dave/ros/src/qt_gui_cpp/src/qt_gui_cpp_shiboken && /usr/bin/shiboken --generatorSet=shiboken --include-paths=/home/dave/ros/src/qt_gui_cpp/src/qt_gui_cpp_shiboken/../../include::/usr/include/qt4 --typesystem-paths=/usr/share/PySide/typesystems --output-directory=/home/dave/ros/build_isolated/qt_gui_cpp/src/qt_gui_cpp_shiboken global.h typesystem.xml

Any ideas why this happens?

It's a recurring error on debian, as I've already told it just happened also the first days of september...

I've also tryed to downgrade to the version 0.2.17-0, but nothing changes...
I don't know if is a configuration problem or a serious isue, but iin ros answer there is other people with the same problem using debian...

[DorianScholz]

Unfortunately I have no idea why this happens and have no Debian system to test it on.

But here are some hints how to work around this, if you are just looking to get rqt running on your system.
Shiboken is only needed if you want to run rqt cpp plugins (i.e. rviz or image viewer) using PySide (LGPL) instead of PyQt (GPL).
If you are happy to work with PyQt, which is the default anyhow, you don't need to compile the shiboken part:

• just uninstall shiboken completely
• re-build qt_gui_cpp, it should just skip the shiboken (PySide) bindings and only compile the SIP (PyQt) ones

[boris-il-forte]

thank you very much, it worked!
But, why if PyQt is the default, when compiling is considered first shiboken?
So, the only "problem" with PyQt is the GPL license?

[DorianScholz]

Glad I could help.
PyQt is default, because it was much more stable (and still is, i guess) than PySide.
PySide is only in for the less restrictive license.
But if you have both binding tools (SIP and Shiboken) installed, it will try to build both bindings.

[dirk-thomas]

Since disabling shiboken is not actually a fix and I got one more report that the same happens on Ubuntu Saucy I will reopen this ticket.

[boris-il-forte]

sorry, I supposed that it wasn't happening on ubuntu by the things @DorianScholz says...
I can add some extra information:
The first time I've built qt_cpp_gui, I was using libboost-1.49 and shiboken 1.1.2-4, and failed to build (shiboken segfaults). It was by the end of september.
Then i've updated shiboken at 1.2.1-2 and I've managed to build the package correctly.
Now, for some reasons, I had to rebuild all the ros stuff, and now shiboken crashes again. I'm using libboost1.54, but also another computer with debian Jessie but the old version of boost libraries behave in the same way...

I've also tried using an older version of qt_gui_cpp, synchronizing the dependencies, and shiboken still crashes...

I don't know what others packages important for building the bindigs were updated in this lapse of time, because I'm not exactly an expert of python...

[dirk-thomas]

Have you wiped your build and devel folders after changing system packages? If not the crashes might just be related to using a different version after originally configuring for another version.

[boris-il-forte]

I'm almost sure that I've deleted both folders... but to be 100% sure I've moved the old builds and I'll try to build again all the packages as soon as possible...

[boris-il-forte]

ok, I've done:
cd ros/
rm -rf build_isolated
rm -rf devel_isolated
catkin_make_isolated -j8
building the entire ros system, to be sure that wasn't a compatibility problem (ok, I left my ros system installed in /opt/ros/hydro, but this shouldn't be a problem, as it was built already with the new system...)
and of course shiboken still crashes.

I'm almost sure that my first build was done with an empty workspace, but now i can confirm that for sure.

I can give any information/help you want, if you want to fix this. Just tell me what you want to know.

Still, I think that the workaround is a pretty good solution to this problem, that seems to occur a bit frequently on debian...

[jonbinney]

I'm seeing this same issue on ubuntu saucy. I followed the source install instructions for installing hydro from source and I get this segfault when compiling.

[jonbinney]

I replaced shiboken with a shell script that runs shiboken in gdb, and caught the segfault, but the backtrace is not helpful...

Program received signal SIGSEGV, Segmentation fault.
0x00000000004d624 in ?? ()
(gdb) bt
#0 0x00000000004d4624 in ?? ()
#1 0x00000000004dbe6e in ?? ()
#@ 0x00000000004b3a73 in _start ()

[boris-il-forte]

just a tip: if you run make -n you can see wich command is called by make. So you don't need to change shiboken with a shell script ;)
(if you see, when build fails you get a command to run to reproduce, wich is make...)

you should compile shiboken with debug symbols to get debug information... but I think the issue is not in qt_gui_cpp, but in shiboken itself and should be fixed upstream...

A bug should be opened in a bug tracker...

[jonbinney]

If i can come up with a simpler way to reproduce I'll file an upstream bug. Otherwise they're not likely to be able to help (see this similar bug that never got resolved: http://srinikom.github.io/pyside-bz-archive/1054.html)

[kelvinji2009]

I encountered the same issue in ubuntu 13.10.
I tried to update shiboken to 1.2.1, but no used.

[kelvinji2009]

Updated: I removed the libshiboken-dev and shiboken, now built successful on ubuntu 13.10.

[jonbinney]

@kelvinji2009 - so are you not building the rqt stuff that uses shiboken?

[kelvinji2009]

@jonbinney Yes.Just use sip.
LOG:
CMake Warning at /home/kelvinji/mitnick/ros/build/ros_catkin_ws/install_isolated/share/python_qt_binding/cmake/shiboken_helper.cmake:23 (message):
Shiboken binding generator NOT available.
Call Stack (most recent call first):
src/python_bindings/shiboken/CMakeLists.txt:9 (include)

-- SIP binding generator available.
Python binding generators: sip
-- Configuring done
-- Generating done

[dirk-thomas]

While it work with shiboken 1.1.1-1 (Ubuntu Quantal) it segfaults with shiboken 1.1.2-4 (Ubuntu Saucy) as well as with shiboken 1.2.1-2 (Ubuntu Trusty).

It looks like shiboken is accessing a non-existing argument (https://qt.gitorious.org/pyside/shiboken/source/a527dd51e69b80c2d5be3a1d8cd60ab2b2616fa5:ApiExtractor/abstractmetabuilder.cpp#L223).

Eventually related to this change between 1.1.1 and 1.1.2?? https://qt.gitorious.org/pyside/shiboken/commit/e40e993cecd1663636e2f0d33b3e2a6204d64984#ApiExtractor/abstractmetalang.cpp

[dirk-thomas]

If someone could come up with a really minimal example which segfaults reproducible that would be great. Then we could:

• try to workaround the problematic code part (if possible)
• fill a precise bug report upstream

Is anybody volunteering to do that?

[goretkin]

I made a not-so-minimal example. It exercises the bug on a fresh install of Ubuntu 13.10. I don't know how to better isolate the packages to install, so right now it requires about 400mb of packages.

Extract the archive here http://people.csail.mit.edu/goretkin/shiboken-test/ and run test.sh. It puts you in the GDB prompt. Type "run" and shiboken eventually segaults.

[dirk-thomas]

Thank you for putting together the example. Based on that I was able to boil it down much more: https://github.com/dirk-thomas/shiboken_segfault_with_boost

It segfaults when including the boost shared pointer header. This does not look like something we can workaround in our code. On the one hand we rely on the interface of class_loader. On the other hand we need to manage the life time of the created instances. We will see how receptive upstream is when filling a ticket about it (pyside/Shiboken#72)...

[goretkin]

Great! I see you added a work-around. How do I get it without needing to start the build over again?

[boris-il-forte]

uhm, that repository seems outdated... last commit 2 years ago...

[dirk-thomas]

@boris-il-forte Good point - I refilled the ticket at https://bugreports.qt-project.org/browse/PYSIDE-218 - hopefully there it gets more attention.

@goretkin There is no work around (except disabling shiboken manually). I can't imagine any other workaround then potentially detecting "broken" versions of shiboken and automatically disabling it.

[boris-il-forte]

I know that's almost impossible with CMake, but it would be good to continue the building even when shiboken fails to build.

The biggest issue is that shiboken is installled as rosdep dependency, and it's not clearly pointed out that shiboken it's not mandatory, so I thik a lot of people will face this issue, with no idea on what to do to solve it.
I know that building from source is only for "advanced users" but it seems a bit strage that the default build system has such a big problem, that causes all the build fails for an optional package, totally unnecessary for most users...

I think that would be good to put shiboken bindings in another package, or do not force the installation of shiboken with rosdep, or alternative to have a way, to disable, by default, the building of such code, and let people ho really want shiboken bindings to setup the build intentionally, as they will know exactly what they are doing (instead most of the users, like university students like me, want to build ros for make working they robotic systems and they have no issues on license)

It would be better also to fix this issue upstream, but similar issues could appear over and over again...

[dirk-thomas]

I agree that we should aim to make a from source build succeed. But removing shiboken support from rqt because of a shiboken bug is not a valid option (especially since it works perfectly fine with different versions).

A temporary workaround in the CMake code for qt_gui_cpp to disable shiboken when a "broken" version is detected seems like the "best" approach and is absolutely doable.