Package Details: gazebo 9.3.1-1

Git Clone URL: https://aur.archlinux.org/gazebo.git (read-only)
Package Base: gazebo
Description: A multi-robot simulator for outdoor environments
Upstream URL: http://gazebosim.org/
Licenses: Apache
Submitter: None
Maintainer: GPereira
Last Packager: GPereira
Votes: 22
Popularity: 0.306693
First Submitted: 2008-10-18 22:59
Last Updated: 2018-09-08 12:40

Dependencies (31)

Sources (1)

Latest Comments

1 2 3 4 5 6 ... Next › Last »

miramur commented on 2018-09-16 06:46

EDIT 2: Alright, this package at least builds (with a lot of OGRE_DEPRECATED warnings) with a manually installed ogre-1.10.12. No word yet on whether things work at run time.

For those coming here while trying to build ros-melodic, FIRST install ogre-1.10.12 manually from source, then remove ogre as a dependency of this package and remove ogre-1.9 as a dependency of rviz.


EDIT: gazebo 9.3.1-1 relies on an ogre setMaterial() interface that was deprecated last August and removed in February (https://github.com/OGRECave/ogre/commit/114fe48c7e3959ca47a47490d16ec6d630ae410a#diff-f8a87d2c9e82f5de4ef37d15c3972672)

It's not going to build with anything after v1.10.12 (e.g. the dependency 'ogre,' which is 1.11). I'll see if it works w/ ogre 1.10.


So I tried building this w/ Ogre v1.11.2 installed manually. Unfortunately, I still get the missing header file:

#include <OGRE/OgreWindowEventUtilities.h>

And even when I move the header file out the "Bites" folder, I get compile errors suggesting a reliance on old ogre code:

error: no matching function for call to ‘gazebo::rendering::DynamicLines::setMaterial(std::__cxx11::string&)’
   dPtr->torqueLine->setMaterial(dPtr->unselectedMaterial);

/usr/include/OGRE/OgreSimpleRenderable.h:76:22: note: candidate: ‘virtual void Ogre::SimpleRenderable::setMaterial(const MaterialPtr&)’
         virtual void setMaterial(const MaterialPtr& mat);

Perhaps this actually looking for an older version of ogre than 1.11 or 1.9?

jlecoeur commented on 2018-09-11 08:32

@nicolino there are the three OGRE releases 1.11.0, 1.11.1 and 1.11.2 here: https://github.com/OGRECave/ogre/releases.

If it works with version 1.11.2, what about adding an AUR ogre-1.11.2 package and make it a hard requirement for the AUR gazebo package?

nicolino commented on 2018-09-10 14:17

Hi,

I have tried to install various source version of ogre (the various ogre* packages on AUR) but no one of them was perfectly compatible with the current version of gazebo.

Recap:

Current version of gazebo with precompiled ogre binary: does compile but does not work entirely: exception + segfault when loading complex models from the online repo (i.e. something that has a texture). The actual point of failure is when gazebo calls the ogre subsystem to load the .material files: Ogre::ResourceGroupManager::getSingleton().openResource() that lie inside the ogre libraries (/usr/lib/libOgreMain.so).

So the sources of ogre are needed to go through them with a debugger.

Current version of gazebo with various combinations of source ogre: does not compile. Gazebo sort of "wants" ogre 1.11 but it is not available as a AUR package.

I am thinking of getting and installing ogre from THE OGRE repository, but it is more or less against Arch policy (outside AUR).

Ideas?

Best Regards

NOTE: To go back to previous version of gazebo (9.0), that was compatible with ogre 1.10, requires OLD BOOST.

NOTE2: Apparently, there is not a version 1.11 on the ogre website (https://bitbucket.org/sinbad/ogre/src).

nicolino commented on 2018-09-10 12:21

Hi,

The very last version of gazebo has still the same segmentation fault after the exception in loading material files.

I am recompiling ogre-git with debug symbols and seeing what's wrong.

However, the time window for which I can dedicate resources to drill into this subject is closing, please consider taking charge.

@jlecoeur:

I do not know why, but the ogre patch is missing from the package (also commented in the PKGBUILD). I have managed to make the last version compile by downloading the modified ogre-1.11.patch (thanks AGAIN to @nodabba): https://gist.github.com/n0dabba/bd586b466da068e2eb9a24c003d507c1, putting it in the source dir and decommenting the PKGBUILD.

@Teasp00n:

No, the patch (ogre-1.11) is still good AND necessary.

The problem is inside the (precompiled as in binary package) Ogre libraries.

Best Regards

jlecoeur commented on 2018-09-10 10:07

The build is still broken

Scanning dependencies of target gazebo_rendering
[ 43%] Building CXX object gazebo/rendering/CMakeFiles/gazebo_rendering.dir/ApplyWrenchVisual.cc.o
In file included from /tmp/yaourt-tmp-jlecoeur/aur-gazebo/src/osrf-gazebo-5714795a2e79/gazebo/rendering/MovableText.hh:27,
                 from /tmp/yaourt-tmp-jlecoeur/aur-gazebo/src/osrf-gazebo-5714795a2e79/gazebo/rendering/ApplyWrenchVisual.cc:24:
/tmp/yaourt-tmp-jlecoeur/aur-gazebo/src/osrf-gazebo-5714795a2e79/gazebo/rendering/ogre_gazebo.h:34:10: fatal error: OGRE/OgreWindowEventUtilities.h: No such file or directory
 #include <OGRE/OgreWindowEventUtilities.h>
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [gazebo/rendering/CMakeFiles/gazebo_rendering.dir/build.make:63: gazebo/rendering/CMakeFiles/gazebo_rendering.dir/ApplyWrenchVisual.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:2583: gazebo/rendering/CMakeFiles/gazebo_rendering.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

Teasp00n commented on 2018-09-08 13:34

Did you mean to remove the ogre-2.11 patch from the sources?

nicolino commented on 2018-09-08 11:51

Hi,

sorry for the mess, I am of the EE bunch, not ITC, my approach to coding is more or less "BRUTAL".

New version of gazebo crashes every-single-time a specific subset of models is loaded from the online repository.

The specific subset of models is identified by the presence, in all of its component models, of extra materials. In other words: textures and relative .material files.

I have managed to run gzclient through gdb (gzserver is running on its own) and I found out that the crash is generated by an exception catched in the file gazebo/rendering/RenderEngine.cc, the same in which the patch about the extra plugins (see below) had to be applied.

The exception is generated in the try block of RenderEngine:479 and, in detail, at line 509:

509            Ogre::DataStreamPtr stream =
510              Ogre::ResourceGroupManager::getSingleton().openResource(
511                  fullPath.string(), "General");

Inspecting the variable, fullPath is correct, but executing call fullPath.string() throws out a syntax error (in the debugger).

Browsing through the Boost Libraries Reference (https://www.boost.org/doc/libs/1_67_0/libs/filesystem/doc/reference.html) I have found out that there is not a unparametrized string() function.

There is indeed an unparametrized template <class String> String generic_string() const indeed, and inspecting with call fullPath.generic_string() returns the correct file path.

Recompiling with generic_string still catches an exception from the very same function Ogre::ResourceGroupManager::openResource().

After that, gdb loses its track inside /usr/lib/libOgreMain.so with Cannot find bounds of current function before returning with the exception catched and me losing my patience.

I do not know from how long this was going on but I reckon never being able to open certain models (FROM THE ONLINE REPO AVAILABLE INSIDE THE PROGRAM) in gazebo. After clicking on the model, nothing happened.

I suspect that the exception has always been thrown. The difference is that with the new boost and ogre, this time the program returns execution.

So:

1) Am I missing something important in a very, very dumb way?

2) In case there is a real problem with the code:

2a) Does anyone have the possibility to debug the rest of the OgreMain?

2b) Should we notify upstream?

If you want to replicate the experiments remember to recompile the code with -g -O0 as, in other cases, optimization changes in the source are significant.

Best Regards.

nicolino commented on 2018-09-06 09:33

Hi,

I would like to remind that I did not concoct the patch, I just found the useful part in the @nodabba comment and highligted it.

Best Regards

kikislater commented on 2018-09-04 07:23

So is it possible to put nicolino patch in build ?

cptnapalm commented on 2018-08-28 22:49

Just to be an additional confirmation, the portion of the patch pointed out by nicolino does, in fact, cures the 'png' codec problem during compilation.