Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue in base/types building #131

Open
Josemi-SW opened this issue Feb 25, 2019 · 15 comments
Open

Issue in base/types building #131

Josemi-SW opened this issue Feb 25, 2019 · 15 comments

Comments

@Josemi-SW
Copy link

Hi!,

Im using Ubuntu18.04 with ruby version 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux-gnu]

Base/types build process fails saying:

[ 46%] Generating moc_DistanceImageVisualization.cxx
cd /home/esrocos/ROCK_INSTALL/base/types/build/viz && /usr/lib/x86_64-linux-gnu/qt4/bin/moc @/home/esrocos/ROCK_INSTALL/base/types/build/viz/moc_DistanceImageVisualization.cxx_parameters
/usr/include/boost/predef/language/stdc.h:52: Parse error at "defined"
viz/CMakeFiles/base-viz.dir/build.make:62: recipe for target 'viz/moc_DistanceImageVisualization.cxx' failed
make[2]: *** [viz/moc_DistanceImageVisualization.cxx] Error 1
make[2]: Leaving directory '/home/esrocos/ROCK_INSTALL/base/types/build'
CMakeFiles/Makefile2:140: recipe for target 'viz/CMakeFiles/base-viz.dir/all' failed
make[1]: *** [viz/CMakeFiles/base-viz.dir/all] Error 2
make[1]: Leaving directory '/home/esrocos/ROCK_INSTALL/base/types/build'
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2

As a workarround I have change base/types/viz/CMakelist.txt to avoid using moc tool to that file, but is it compiled. Patch applied:

--- CMakeLists.txt_old	2019-02-25 10:37:15.390005000 +0100
+++ CMakeLists.txt	2019-02-25 10:37:31.282005000 +0100
@@ -1,7 +1,7 @@
 rock_vizkit_plugin(base-viz
     PluginLoader.cpp Uncertainty.cpp Vizkit3DHelper.cpp
+    DistanceImageVisualization.cpp 
     MOC 
-        DistanceImageVisualization.cpp 
         LaserScanVisualization.cpp 
         MotionCommandVisualization.cpp 
         RigidBodyStateVisualization.cpp

There are also many, like the one below, warnings but those ones do not affect to the build process.

....ruby.hpp:73:29: warning: ‘template<class'> class std::auto_ptr is deprecated

Josemi.

@doudou
Copy link
Member

doudou commented Mar 21, 2019

This is probably caused by an incompatibility of Qt4's moc parser and C++11.

I can't reproduce it here .... are you building a custom branch maybe ? Can you send the result of git show HEAD in base/types ?

@Josemi-SW
Copy link
Author

This is the output I get

commit b6364d75fc09223accac830dedbfcb59acfef061 (HEAD -> master, autobuild/master, autobuild/HEAD)
Merge: 1995f61 6d06bbb
Author: elael <[email protected]>

Date:   Mon Feb 18 16:48:26 2019 -0300
    Merge pull request #129 from rock-core/remove_length_in_pretty_print  
	ruby: do not display the curve length while pretty-printing SISL::Spline

@doudou
Copy link
Member

doudou commented Mar 25, 2019

OK ... so not that.

I really am at a loss here. I'm building without problem, on 18.04 too.

@chhtz
Copy link
Contributor

chhtz commented Mar 25, 2019

You may have different boost-versions installed or perhaps you are using different Qt-versions. A workaround could be to guard any boost-includes by something like:

#if QT_VERSION >= 0x050000 || !defined(Q_MOC_RUN)

We had to do this, e.g., here:
https://github.com/envire/slam-maps/pull/22/files

@m0rsch1
Copy link

m0rsch1 commented Jul 10, 2020

I have encountered that bug as well. This is serious because a base/types build error breaks everything else.

@doudou
Copy link
Member

doudou commented Jul 10, 2020

I have encountered that bug as well. This is serious because a base/types build error breaks everything else.

I agree. Now, it happens that we can't reproduce the problem both on 18.04 and 20.04. The latter has a fairly recent boost version (so, my guess is "not boost").

Without more info, there's really nothing we can do from where we sit.

@m0rsch1
Copy link

m0rsch1 commented Jul 10, 2020

I have found something here:
https://rayleizhu.com/?p=102

But that sounds like a rather complicated patch

@doudou
Copy link
Member

doudou commented Jul 10, 2020

Before we start chasing fixes, I'd like to understand the actual problem - and in particular why it happens seemingly rarely. Again, the package builds fine on most machines with the boost version from both 18.04 and 20.04 (1.71.1). We need someone to start looking at why it happens on your particular machine(s). A.k.a. you at least need to tell us what's different between your build and the vanilla rock-core build.

Also, it would be helpful that you do a vanilla build (a plain install using rock-core's buildconf) and see whether it happens there.

@m0rsch1
Copy link

m0rsch1 commented Jul 10, 2020

My boost is version 1.65

More precise:
#define BOOST_VERSION 106501

@m0rsch1
Copy link

m0rsch1 commented Jul 10, 2020

Qt4 is Qt version 4.8.7

@doudou
Copy link
Member

doudou commented Jul 10, 2020

My guess would be that there is something fishy on the systems where this bug happens. Maybe some patches lying around, maybe some self-installed versions of boost or qt4 that mess up with the build (have you ever done a sudo make install ?). I don't know.

A vanilla 18.04 builds rock-core fine. So are a lot of non-vanilla (i.e. in-use for years) 18.04. And some 16.04 and some 20.04 (mine). I'm happy to help you track the problem, but based on the information I have so far, I believe the most likely source is your system, not base/types.

vagrant@ubuntu1804:~$ apt-cache policy libqt4-dev
libqt4-dev:
  Installed: 4:4.8.7+dfsg-7ubuntu1
  Candidate: 4:4.8.7+dfsg-7ubuntu1
  Version table:
 *** 4:4.8.7+dfsg-7ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/universe amd64 Packages
        100 /var/lib/dpkg/status
vagrant@ubuntu1804:~$ apt-cache policy libboost-dev
libboost-dev:
  Installed: 1.65.1.0ubuntu1
  Candidate: 1.65.1.0ubuntu1
  Version table:
 *** 1.65.1.0ubuntu1 500
        500 http://us.archive.ubuntu.com/ubuntu bionic/main amd64 Packages
        100 /var/lib/dpkg/status

@m0rsch1
Copy link

m0rsch1 commented Aug 3, 2020

I tried the vanilla installation today. Unfortunately the bug remains:

[ 46%] Linking CXX shared library libbase-types.so
[ 46%] Built target base-types
[ 48%] Generating moc_TrajectoryVisualization.cxx
Scanning dependencies of target base_types_ruby
[ 49%] Building CXX object bindings/ruby/CMakeFiles/base_types_ruby.dir/ext/base_types_ruby/Eigen.cpp.o
[ 50%] Generating moc_DistanceImageVisualization.cxx
/usr/include/boost/predef/language/stdc.h:52: Parse error at "defined"
viz/CMakeFiles/base-viz.dir/build.make:62: recipe for target 'viz/moc_DistanceImageVisualization.cxx' failed
make[2]: *** [viz/moc_DistanceImageVisualization.cxx] Error 1
CMakeFiles/Makefile2:204: recipe for target 'viz/CMakeFiles/base-viz.dir/all' failed
make[1]: *** [viz/CMakeFiles/base-viz.dir/all] Error 2
make[1]: *** Auf noch nicht beendete Prozesse wird gewartet …
[ 51%] Building CXX object bindings/ruby/CMakeFiles/base_types_ruby.dir/ext/base_types_ruby/Spline.cpp.o
[ 53%] Building CXX object bindings/ruby/CMakeFiles/base_types_ruby.dir/ext/base_types_ruby/init.cpp.o
[ 54%] Linking CXX shared module base_types_ruby.so
[ 54%] Built target base_types_ruby
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2
Exit: pid 14743 exit 2

@m0rsch1
Copy link

m0rsch1 commented Aug 3, 2020

See also this bug report.

I am preparing a patch to this issue.
EDIT: There is already an open pull request to this issue.

@doudou
Copy link
Member

doudou commented Aug 3, 2020

I tried the vanilla installation today. Unfortunately the bug remains:

By "vanilla", I meant: rock-core from scratch within a vanilla 18.04 (a.k.a. a virtual machine in my case). Is that what you did ?

@m0rsch1
Copy link

m0rsch1 commented Aug 3, 2020

Nope. By "vanilla" I meant a basic rock installation (bootstrap from website).
If I find the time to do it I will post it here. In the meantime I will stick to that open pull request which fixes everything for me right now :)
It is definitely not a base/types issue but a Qt/boost issue ... on some systems. Maybe also a Qt4/Qt5 mixup, but it is hard to investigate.

EDIT: By the way, if that pull request solves problems for some and does not introduce any problems for others, why can't we just accept it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants