Arch Linux User Repository

Development is on Github: https://github.com/acxz/gazebo-arch Please open issues and PRs there instead of commenting.

Development is on Github: https://github.com/acxz/gazebo-arch Please open issues and PRs there instead of commenting.

I have finally been able to spend some time getting this package working again and bumping the version to 11.10.2.

Unfortunately, several of the ignition-* dependencies are not building because of issues with those packages, but I've sent fixes, so hopefully they'll be working again soon.

@leuko It appears that the compilation error was fixed in https://github.com/osrf/gazebo/commit/2f0f7af4868883d1a6fea30086b3fcd703d583fc, which is (as of this writing) the current HEAD.

Tried to compile 11.10.2. I can confirm that protobuf 3.20 causes an error during compilation.

Gazebo (even the updated version 11.10.2) seems to be unable to compile with the latest protobuf (3.20.1). In case anyone else runs into this, the only workaround without upstream changes that I've found so far is downgrading protobuf.

I found this alternative way to compile gazebo without uninstalling ffmpeg5.

sudo pacman -S ffmpeg4.4
export PKG_CONFIG_PATH=/usr/lib/ffmpeg4.4/pkgconfig
yay -S gazebo

Currently for ignition-common-3 you have to uninstall ffmpeg and replace with ffmpeg4.4. Try this

sudo pacman -Rd --nodeps ffmpeg
sudo pacman -S ffmpeg4.4
yay -S ignition-common-3
yay -S gazebo
yay -S ffmpeg # since ffmpeg is now at version 5

Hi @joanmanel. When you install packages a lot of the times you don't have the packages that the package you're interested in depends on. If you're using the aur helper yay, I'm pretty sure it tries to install the dependencies automatically. The output you pasted is actually an error message for ignition-common-3 not gazebo.

Hi, trying to install gazebo for the first time, I get the following error, I wonder if you could tell me how to fix it:

[ 33%] Building CXX object av/src/CMakeFiles/ignition-common3-av.dir/AudioDecoder.cc.o
/tmp/yaourt-tmp-juanma/aur-ignition-common-3/src/ign-common-ignition-common3_3.14.0/av/src/AudioDecoder.cc: In member function ‘bool ignition::common::AudioDecoder::Decode(uint8_t**, unsigned int*)’:
/tmp/yaourt-tmp-juanma/aur-ignition-common-3/src/ign-common-ignition-common3_3.14.0/av/src/AudioDecoder.cc:135:24: error: ‘avcodec_decode_audio4’ was not declared in this scope; did you mean ‘avcodec_decode_subtitle2’?
  135 |         bytesDecoded = avcodec_decode_audio4(this->data->codecCtx, decodedFrame,
      |                        ^~~~~~~~~~~~~~~~~~~~~
      |                        avcodec_decode_subtitle2
/tmp/yaourt-tmp-juanma/aur-ignition-common-3/src/ign-common-ignition-common3_3.14.0/av/src/AudioDecoder.cc: In member function ‘bool ignition::common::AudioDecoder::SetFile(const string&)’:
/tmp/yaourt-tmp-juanma/aur-ignition-common-3/src/ign-common-ignition-common3_3.14.0/av/src/AudioDecoder.cc:227:44: error: ‘AVStream’ {aka ‘struct AVStream’} has no member named ‘codec’
  227 |     if (this->data->formatCtx->streams[i]->codec->codec_type == // NOLINT(*)
      |                                            ^~~~~
/tmp/yaourt-tmp-juanma/aur-ignition-common-3/src/ign-common-ignition-common3_3.14.0/av/src/AudioDecoder.cc:253:31: error: ‘AVStream’ {aka ‘struct AVStream’} has no member named ‘codec’
  253 |     this->data->audioStream]->codec;
      |                               ^~~~~
/tmp/yaourt-tmp-juanma/aur-ignition-common-3/src/ign-common-ignition-common3_3.14.0/av/src/AudioDecoder.cc:259:43: error: invalid conversion from ‘const AVCodec*’ to ‘AVCodec*’ [-fpermissive]
  259 |   this->data->codec = avcodec_find_decoder(this->data->codecCtx->codec_id);
      |                       ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                           |
      |                                           const AVCodec*
make[2]: *** [av/src/CMakeFiles/ignition-common3-av.dir/build.make:76: av/src/CMakeFiles/ignition-common3-av.dir/AudioDecoder.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:395: av/src/CMakeFiles/ignition-common3-av.dir/all] Error 2
make: *** [Makefile:146: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
==> ERROR: Makepkg was unable to build ignition-common-3.
==> Restart building ignition-common-3 ? [y/N]

It's no problem. Just as long as someone is on it. Do you have a separate repository where people can create merge requests for the package build?

@bobosito: Yeah, exactly!

Apologies to all that this package has been out of date for so long. Currently gazebo requires patching to work with the latest version of tbb and I haven't yet had a chance to rebase my patchset onto the latest version.

The patching path is correct. After the patch is downloaded a link is made to the patch file inside of the src folder.

I think the patching is done from the wrong path. Shouldnt it be:

patch -p1 < ../../fix-for-tbb-2021.patch

It's no problem. Sorry for the late reply. Everyone has to start somewhere. Just append -j3 to the ninja command in the pkgbuild. I don't think ninja reads parallel job number from any environment variable.

@bobosito, I am new to package building in Arch. Can you please tell me what changes can I make in my files to compile this package? Should I append $NINJAFLAGS="-J2" to the line inside build() function having ninja? What else can I do? I have a 4 core laptop.

I got it building on my system without hanging by changing the number of parallel jobs in the PKGBUILD.

I tried changing the number of parallel jobs in MAKEFLAGS in /etc/makepkg.conf. Apparently, ninja only uses an environment variable called NINJA_STATUS and you can't pass flags to ninja using it, so that doesn't work. You could pass MAKEFLAGS to ninja as an argument, but you shouldn't do that cuz ninja doesn't support all of make's flags.

Could write up a bashscript to strip the job number from makeflags and put it into ninja as command line argument or switch to make?

I feel like unless there's something in the configuration to fix that memory issue that I'm missing, it should be handled in the PKGBUILD cuz it would mean for some users it will hang unless they edit the PKGBUILD.

My PC runs out of memory while building, and I'm not building in /tmp. What changes would I have to make to /etc/makepkg.conf?

I did see it, but didn't edit anything because I was having problems with PCL package too, so I shifted to Linux Mint for now.

So... your PC runs out of memory? Did you follow the suggestions I made before (e.g. edit options in makepkg.conf)?

This package does not get build completely. It hangs my laptop at this point after which the only option left is to forcefully restart my PC using the power button.

Does this package (i.e. gazebo, not gazebo-git) build successfully for you or not? I'm confused.

I see. I have emailed the author about the issue, meanwhile can you please suggest me what I can do to build your package successfully?

@Kanishk598: FYI I don't maintain the gazebo-git package. It seems like that package is missing the tbb fix that I have in mine though.

Thank you, that was indeed a problem of full memory consumption. I shifted to installing gazebo-git instead of gazebo, and encountered this error. Can you please help me solve this? I have installed all the required dependencies one by one from the list of dependencies above, but didn't install the optional ones. Also, this time my laptop didn't hang but just failed the installation.

It sounds like your machine could be running out of memory. There are a couple of things that could cause this. If you're building in /tmp this could gobble up your RAM, as well as building on lots of cores (see /etc/makepkg.conf).

Check your memory usage while building gazebo to see if that's the issue.

I am installing ROS in Manjaro linux kernel 5.10, and while installing Gazebo it hangs my complete laptop at the point in this image

Please tell me what can I do to install ROS in Manjaro?

There is a missing dependency: openal: which is not part of extra/ffmpeg (as opposed to the Ubuntu repos)

- BUILD WARNINGS
--      OpenAL not found, audio support will be disabled.
--      Simbody not found, for simbody physics engine option, please install libsimbody-dev.
--      DART 6.6 not found, for dart physics engine option, please install libdart6.6-dev.
--      Player not found, gazebo plugin for player will not be built.
--      Bullet > 2.82 not found, for bullet physics engine option, please install libbullet2.82-dev.
--      Oculus Rift support will be disabled.
--      OpenSource Virtual Reality (OSVR) support will be disabled.
-- END BUILD WARNINGS

@lalten I've got a temporary workaround in place so it should now work. I'm working on a PR and hopefully that'll get merged soon so this isn't an issue going forward.

Compilation of this package fails because Gazebo is not compatible with intel-tbb >= 2021.01: https://github.com/osrf/gazebo/issues/2867

@fkl: I'm afraid I don't know how to fix your issue though. I don't know any more than you do here, but hopefully the ogre maintainers will know more. Arch is a DIY distro, so you do have to be prepared to dig in to problems yourself when they arise.

@billypilgrim At the end of the day, I need Gazebo.

The installation instructions at http://gazebosim.org/tutorials?tut=install_other_linux&cat=install are based on this AUR.

@fkl: Try contacting the upstream maintainers of ogre.

@billypilgrim I thought the AUR maintainer of ogre-1.9 and packages that depend it (e.g. gazebo) would know something about it. Unfortunately, I am the only person who has this issue.

@fkl: You should post that comment on the ogre1.9 package's page so that its maintainer can do something about it. This isn't an issue with the gazebo PKGBUILD per se.

I am unable to build this package due to what looks to be an upstream issue (https://github.com/acxz/pkgbuilds/issues/151) with ogre-1.9.

I am wondering why I am the only person who is having this issue.

During the compilation of /opt/AUR/ogre-1.9/src/ogre-1.9.1/OgreMain/src/OgreRoot.cpp:

/opt/AUR/ogre-1.9/src/ogre-1.9.1/OgreMain/include/Threading/OgreDefaultWorkQueueTBB.h:42:25: error: looser exception specification on overriding virtual function ‘virtual Ogre::DefaultWorkQueue::~DefaultWorkQueue() noexcept (false)’

   42 |                 virtual ~DefaultWorkQueue();

In file included from /opt/AUR/ogre-1.9/src/ogre-1.9.1/OgreMain/include/OgreRoot.h:39,
                 from /opt/AUR/ogre-1.9/src/ogre-1.9.1/OgreMain/src/OgreRoot.cpp:31:
/opt/AUR/ogre-1.9/src/ogre-1.9.1/OgreMain/include/OgreWorkQueue.h:369:25: note: overridden function is ‘virtual Ogre::DefaultWorkQueueBase::~DefaultWorkQueueBase() noexcept’
  369 |                 virtual ~DefaultWorkQueueBase();

This popular AUR should have co-maintiner(s) so the package could be updated sooner.

Good point! This bug has bitten me too in the past. I've applied your fix now.

Hello !

This package ships a GAZEBO_CXX_FLAGS with '-std=c++11'. This is breaking downstream packages that require C++14 or C++17, which should work by default with Arch's GCC 11 as it defaults to C++17.

Could we patch this ? a "sed -i '/-std=c++11/d' cmake/gazebo-config.cmake.in" seems to be enough :)

No that's ok! Let's leave it there for posterity.

I've done the same kind of thing myself, so dw about it :-)

@billypilgrim Sorry you are completely right. It seemed to be my fault somehow but I still don't why the package did not install as dep during the process. Nevermind I'll try to figure out want went wrong there. Should I delete my previous comment?

@t00manysecrets ruby-mustache is a dependency of ruby-ronn-ng which already is a dependency. Is ruby-mustache installed on your machine and is it up to date? It seems like ruby is trying to use an old version; might you have installed it as a gem before?

When I wanted to install gazebo today I received the error below while executing the package()-Step DESTDIR="${pkgdir}" ninja install for nearly all 8 components. As far as I can tell gazebo needs the ruby-mustache package so I would suggest adding it to the dependency list because installing the package beforehand avoids this issue. Has anyone noticed a similar problem?

-- Install configuration: "Release"
[1/8] Generating gzprop.1
FAILED: tools/gzprop.1 
cd /tmp/gazebo/gazebo-11.6.0/build/tools && /usr/bin/ronn -r --pipe /tmp/gazebo/gazebo-11.6.0/tools/gzprop.1.ronn > /tmp/gazebo/gazebo-11.6.0/build/tools/gzprop.1
/usr/lib/ruby/3.0.0/rubygems/specification.rb:1404:in `rescue in block in activate_dependencies': Could not find 'mustache' (~> 1.0) among 125 total gem(s) (Gem::MissingSpecError)
Checked in 'GEM_PATH=/home/frederik/.local/share/gem/ruby/3.0.0:/usr/lib/ruby/gems/3.0.0' at: /usr/lib/ruby/gems/3.0.0/specifications/ronn-ng-0.9.1.gemspec, execute `gem env` for more information
    from /usr/lib/ruby/3.0.0/rubygems/specification.rb:1401:in `block in activate_dependencies'
    from /usr/lib/ruby/3.0.0/rubygems/specification.rb:1390:in `each'
    from /usr/lib/ruby/3.0.0/rubygems/specification.rb:1390:in `activate_dependencies'
    from /usr/lib/ruby/3.0.0/rubygems/specification.rb:1372:in `activate'
    from /usr/lib/ruby/3.0.0/rubygems.rb:302:in `block in activate_bin_path'
    from /usr/lib/ruby/3.0.0/rubygems.rb:301:in `synchronize'
    from /usr/lib/ruby/3.0.0/rubygems.rb:301:in `activate_bin_path'
    from /usr/bin/ronn:23:in `<main>'
/usr/lib/ruby/3.0.0/rubygems/dependency.rb:313:in `to_specs': Could not find 'mustache' (~> 1.0) - did find: [mustache-0.99.8] (Gem::MissingSpecVersionError)
Checked in 'GEM_PATH=/home/frederik/.local/share/gem/ruby/3.0.0:/usr/lib/ruby/gems/3.0.0' , execute `gem env` for more information
    from /usr/lib/ruby/3.0.0/rubygems/specification.rb:1402:in `block in activate_dependencies'
    from /usr/lib/ruby/3.0.0/rubygems/specification.rb:1390:in `each'
    from /usr/lib/ruby/3.0.0/rubygems/specification.rb:1390:in `activate_dependencies'
    from /usr/lib/ruby/3.0.0/rubygems/specification.rb:1372:in `activate'
    from /usr/lib/ruby/3.0.0/rubygems.rb:302:in `block in activate_bin_path'
    from /usr/lib/ruby/3.0.0/rubygems.rb:301:in `synchronize'
    from /usr/lib/ruby/3.0.0/rubygems.rb:301:in `activate_bin_path'
    from /usr/bin/ronn:23:in `<main>'

EDIT: Could this dependency be missing in ruby-ronn instead?

Is there any particular reason why Gazebo still use ancient libxml package rather than libxml2 ? I have successfully build gazebo with libxml2.

@petersill PSA that packages should ONLY be flagged out of date if there is a new upstream version of the software available. If the PKGBUILD is broken, then please just leave a comment.

@AchmadFathoni Thank you for pointing this out. The root cause is that ignition-common-3 doesn't have ignition-common in its provides array. I've posted a message about this: https://aur.archlinux.org/packages/ignition-common-3/#comment-808324

gazebo depends on ignition-fuel_tools-4 which is depends on ignition-common-3. But gazebo itself depends on ignition-common. Replace ignition-common>=3 with ignition-common-3 may solve this problem.

got

:: Resolving dependencies...
:: There are 3 providers available for gazebo:
:: Repository AUR:
    1) gazebo  2) gazebo-10  3) gazebo-git
Enter a number (default=1):
:: Calculating conflicts...
:: Calculating inner conflicts...
:: Marked out of date: ignition-common

Aur (4) ignition-common-3.9.0-1  ignition-common-3-3.13.1-1  ignition-fuel_tools-4-4.3.0-1  gazebo-11.5.1-1

:: Proceed to review? [Y/n]: n

The double ignition-common and ignition-common-3 lead to package exists in the filesystem error

11.5.0 is released in https://github.com/osrf/gazebo/releases. Should this AUR be updated?

But the ruby-ronn-ng package has ruby-ronn in its provides array so it really shouldn't matter, i.e. yay (or whatever) should just install ruby-ronn-ng for you.

Also, don't flag packages out of date for issues like this. They should only be flagged out of date when there is a newer version of the software available.

got

/usr/lib/ruby/3.0.0/rubygems.rb:281:in `find_spec_for_exe': can't find gem ronn (>= 0.a) with executable ronn (Gem::GemNotFoundException)
    from /usr/lib/ruby/3.0.0/rubygems.rb:300:in `activate_bin_path'
    from /usr/sbin/ronn:23:in `<main>'

Because ruby-ronn has been removed from the [community] repository. please change it to ruby-ronn-ng

Yeah, I must rebuild libdart which is not considered rebuild target by yay.

Sometimes I've found that --rebuildtree isn't enough (I think it could be CMake doing something dumb). Try deleting gazebo and its ignition* deps from .cache/yay before rebuilding, then you'll know that you have a clean src folder.

billypilgrim I've clean-rebuild gazebo with yay -S gazebo --rebuildtree but the problem still there.

AchmadFathoni You need to rebuild the package as it appears that some shared libraries have been updated on your system.

gzserver: error while loading shared libraries: libicudata.so.68: cannot open shared object file: No such file or directory

Any idea?

@codemonkey94 That's good to know. It's still a little odd that ruby-ronn-ng didn't then get pulled in as a dependency when you built it though...

@billypilgrim I had the very same error as @julianoes. I solved by installing ruby-ronn-ng. It seems that ruby-ronn https://archlinux.org/packages/community/any/ruby-ronn/ has been removed from the community repository.

@julianoes Hmm... how's ruby set up on your machine? (I'm not a rubyist so I don't know how it works in terms of installing multiple versions, virtual environments etc.)

ruby-ronn is in the makedepends array, so the required ronn executable ought to be present when the package is being built, unless something strange is going on with your PATH.

I ran into this problem:

[  0%] Generating gzprop.1
/usr/lib/ruby/3.0.0/rubygems.rb:281:in `find_spec_for_exe': can't find gem ronn (>= 0.a) with executable ronn (Gem::GemNotFoundException)
    from /usr/lib/ruby/3.0.0/rubygems.rb:300:in `activate_bin_path'
    from /usr/bin/ronn:23:in `<main>'

...

-- Set runtime path of "/home/julianoes/.cache/yay/gazebo/pkg/gazebo/usr/bin/gzserver-11.4.0" to ""
CMake Error at gazebo/cmake_install.cmake:79 (file):
  file INSTALL cannot find
  "/home/julianoes/.cache/yay/gazebo/src/gazebo-11.4.0/build/gazebo/gzserver.1.gz":
  No such file or directory.
Call Stack (most recent call first):
  cmake_install.cmake:100 (include)

I could workaround this by installing the required ronn gem:

gem install ronn

I installed gazebo properly, but when I ran the gazebo command, the following error showed up: libcdt.so.5:cannot open shared object file: No such file or directory

It turns out I did not have the libcdt library under /usr/lib64/

I searched for a package that provided that, and I installed graphviz

Directly after installing this, I could run gazebo properly. I think it should be listed as a dependency.

Ahh, mystery solved. Nvm then :-)

If one tries to install sdformat-9 before upgrading sdformat to 10, they conflict. Otherwise, if installed / updated in the right order, that's OK :)

@acxz Ah my bad. It does conflict for sdformat though (I tested it), so it would be good to set the conflicts array for that package.

Really? I have both sdformat-9 and sdformat installed. Can you post the error message you get?

@acxz Ah my bad. It does conflict for sdformat though (I tested it), so it would be good to set the conflicts array for that package.

@billypilgrim I think the provides field should be populated but conflicts should remain empty as the two versions shouldn't be conflicting each other. Ignition libraries version their installation directories.

nxxxx: Thanks! That's super helpful :-). Otherwise I'd have ended up doing it myself.

One small suggestion: if you add the original package's name to the provides=() and conflicts=() arrays in the PKGBUILD, it makes it easier for people to upgrade (because pacman knows to e.g. uninstall sdformat before installing sdformat-9).

You can do it like this: provides=(sdformat=$pkgver) conflicts=(sdformat)

I found it would configure failed because of the version of packages :sdformat, ignition-msgs, ignition-transport and ignition-fuel_tools. So I uploaded sdformat-9(https://aur.archlinux.org/packages/sdformat-9/), ignition-msgs-5(https://aur.archlinux.org/packages/ignition-msgs-5/), ignition-transport-8(https://aur.archlinux.org/packages/ignition-transport-8/) and ignition-fuel_tools-4(https://aur.archlinux.org/packages/ignition-fuel_tools-4/) to resolve the problem temporarily.

@billypilgrim bullet seems to be a strict dependency (instead of optional).

@billypilgrim Thx! its been a while (about a year now) since I first started working on packaging/helping package robotics libraries for Arch. The ROS packages (and their deps) have come a long way for sure with everyone's help, but the real milestone will be when we get binary packages out via arch4edu.

@acxz That looks cool! Nice work.

I'd also like to add the following issue that tracks rosdep on Arch Linux: https://github.com/ros-noetic-arch/ros-noetic-desktop-full/issues/4 TLDR: work is in progress on getting package parity with Ubuntu for rosdep, feel free to help out!

@ramdambo you may find this useful

@ramdambo Is there a specific reason why you're using rosdep? What are you trying to achieve?

Bear in mind that packages will be named differently on Arch to Ubuntu. The gazebo package does include headers etc. (as *-dev packages do in Debian/Ubuntu), but, as @acxz points out, this package is for the latest version of gazebo (i.e. the v11 series), not v9, so if ROS requires an older version of gazebo then things might not work.

@ramdambo that makes sense since this package is at version 11 not 9. What ROS are you using? I am using ROS Noetic and have been using this gazebo with it just fine for the past week.

Installed this for use with ROS, but rosdep tells me that libgazebo9-dev is missing. Is this not provided with this package ?

As these issues affect the ignition-math package please address your comments there for the benefit of other users. Plus, I don't maintain that package so I can't fix it.

I did have the same issue though and I was able to fix it by uninstalling swig beforehand (there seems to be a problem with swig and the latest version of ruby). Of course, the cleanest way to build a package is in a clean chroot: https://wiki.archlinux.org/index.php/DeveloperWiki:Building_in_a_clean_chroot

I'm getting the same build error as @msethi during the ignition-math build:

~/.cache/yay/ignition-math/src/ignitionrobotics-ign-math-11bba67b3176/build/src/CMakeFiles/math.dir/Vector3RUBY_wrap.cxx:1270:85: error: call of overloaded ‘rb_define_virtual_variable(const char [21], VALUE (&)(...), NULL)’ is ambiguous
 1270 |   rb_define_virtual_variable("SWIG_TRACKINGS_COUNT", swig_ruby_trackings_count, NULL);
      |                                                                                     ^

https://hastebin.com/yamomazodo.m getting this weird error

I've updated to v11 now, hopefully fixing all the build errors.

v11 is not entirely backwards compatible with v10, so someone might want to fork this package to keep the v10 series around.

@billypilgrim can you add kartikmohta's patch to fix the build?

@kartikmohta Thank you, that was a very good hint. I got it working with

# install gazebo from AUR
yay -S gazebo --noconfirm

# fix incompatible cmake policy that leads to linking error
# see https://aur.archlinux.org/packages/gazebo/#comment-738399
pushd ~/.cache/yay/gazebo/src/gazebo-10.2.0/
sed -i '/endif(COMMAND CMAKE_POLICY)/i \ \ CMAKE_POLICY(SET CMP0100 NEW)' CMakeLists.txt
cd ../..
makepkg -si --noextract --noconfirm
popd

I also had to rebuild ignition-fuel_tools-1, just in case someone is running into the same issue.

@MaEtUgR

You need the following patch to fix compilation with new cmake.

--- gazebo-10.2.0/CMakeLists.txt    2020-04-08 22:50:23.733672485 -0700
+++ gazebo-10.2.0/CMakeLists.txt    2020-04-08 22:22:55.533102191 -0700
@@ -3,6 +3,7 @@
 if(COMMAND CMAKE_POLICY)
   CMAKE_POLICY(SET CMP0003 NEW)
   CMAKE_POLICY(SET CMP0004 NEW)
+  CMAKE_POLICY(SET CMP0100 NEW)
 endif(COMMAND CMAKE_POLICY)

 project (Gazebo)

Thanks all for sorting this out.

Just FYI, as I said before, the v11 series of Gazebo has been released, but I'm still waiting on a fix for swig to reach the main repos before I update it because some of gazebo's dependencies are currently not building.

@MaEtUgR: Sorry, my fault then. Seems like it works in my chroot because one of the deps was built a time ago.

@bionade24 I deleted the comment with the problem description immediately upon your request. I am Arch user. None of it was specific to my setup, I reproduced in a fresh archlinux-latest container and get the exact same output for yay -S gazebo --noconfirm:

[ 72%] Linking CXX executable gazebo
/usr/sbin/ld: gui/libgazebo_gui.so.10.2.0: undefined reference to `gazebo::gui::TerrainEditorPalette::staticMetaObject'
/usr/sbin/ld: gui/libgazebo_gui.so.10.2.0: undefined reference to `vtable for gazebo::gui::IncrementalPlot'
...
/usr/sbin/ld: gui/libgazebo_gui.so.10.2.0: undefined reference to `gazebo::gui::LinkInspector::staticMetaObject'
/usr/sbin/ld: gui/libgazebo_gui.so.10.2.0: undefined reference to `gazebo::gui::ModelPluginInspector::staticMetaObject'
/usr/sbin/ld: gui/libgazebo_gui.so.10.2.0: undefined reference to `gazebo::gui::MainWindow::TrackVisual(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
collect2: error: ld returned 1 exit status
make[2]: *** [gazebo/CMakeFiles/gazebo.dir/build.make:157: gazebo/gazebo-10.2.0] Error 1
make[2]: Leaving directory '/home/builduser/.cache/yay/gazebo/src/gazebo-10.2.0/build'
make[1]: *** [CMakeFiles/Makefile2:2546: gazebo/CMakeFiles/gazebo.dir/all] Error 2
make[1]: Leaving directory '/home/builduser/.cache/yay/gazebo/src/gazebo-10.2.0/build'
make: *** [Makefile:158: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
Error making: gazebo

$ lsb_release -a
LSB Version:    1.4
Distributor ID: Arch
Description:    Arch Linux
Release:    rolling
Codename:   n/a

@MaEtUgR: I don't care about that, I WANTED YOU TO DELETE YOUR COMMENTS NOT TO SWITCH. The AUR is mainly for Arch users and please delete your Manjaro specific comments.

I just tried to rebuild Gazebo using yay -Sy --rebuildtree gazebo and it fails to link for me:

/usr/bin/ld: libgazebo_gui.so.10.2.0: undefined reference to `vtable for gazebo::gui::EditorItem'
/usr/bin/ld: libgazebo_gui.so.10.2.0: undefined reference to `vtable for gazebo::gui::GeometryConfigWidget'
/usr/bin/ld: libgazebo_gui.so.10.2.0: undefined reference to `gazebo::gui::SchematicViewWidget::staticMetaObject'
/usr/bin/ld: libgazebo_gui.so.10.2.0: undefined reference to `gazebo::gui::LogPlayWidget::SetCurrentDays(QString const&)'
/usr/bin/ld: libgazebo_gui.so.10.2.0: undefined reference to `gazebo::gui::VideoRecorder::RecordingChanged(bool)'
/usr/bin/ld: libgazebo_gui.so.10.2.0: undefined reference to `vtable for gazebo::gui::CurrentTimeItem'
/usr/bin/ld: libgazebo_gui.so.10.2.0: undefined reference to `gazebo::gui::ImageView::staticMetaObject'
/usr/bin/ld: libgazebo_gui.so.10.2.0: undefined reference to `gazebo::gui::LinkInspector::staticMetaObject'
/usr/bin/ld: libgazebo_gui.so.10.2.0: undefined reference to `gazebo::gui::ModelPluginInspector::staticMetaObject'
/usr/bin/ld: libgazebo_gui.so.10.2.0: undefined reference to `gazebo::gui::MainWindow::TrackVisual(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
collect2: error: ld returned 1 exit status
make[2]: *** [gazebo/gui/CMakeFiles/gzclient.dir/build.make:299: gazebo/gui/gzclient-10.2.0] Error 1
make[2]: Leaving directory '/home/julianoes/.cache/yay/gazebo/src/gazebo-10.2.0/build'
make[1]: *** [CMakeFiles/Makefile2:3930: gazebo/gui/CMakeFiles/gzclient.dir/all] Error 2
make[1]: Leaving directory '/home/julianoes/.cache/yay/gazebo/src/gazebo-10.2.0/build'
make: *** [Makefile:180: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
Error making: gazebo

Any idea what I should try? Thanks!

@bionade24 Gazebo from your binary repo works fine on my setup. These binaries save so much time. Thanks a lot and keep up the good work!

@MaEtUgR: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#oscloud

I've updated this package to the latest 10.x series version, but v11.0.0 is currently not working (the dependencies won't build) because of this issue: https://github.com/swig/swig/issues/1689

A fix for the swig package is on the way and after that's in the main repos I'll bump this package to v11.

Sweet, the package installs for me now. Thanks @billypilgrim and @DanMan!

Ah my bad. I've added the OpenAL patch back in now.

As @DanMan said, adding the openal patch again to the PKGBUILD file does the job. Thx @DanMan :)

I was able to build by including the moc and openal patch. Not sure why the openal patch was removed after adding the moc patch to the pkgbuild.

Yep it is with a clean build. yay offers to the option to do a clean build when installing. Let me try clean building all AUR deps of gazebo and see if that resolves the issue for me.

EDIT: yep still getting the same error

I'm having the same issue as bionade24 and acxz. gazebo-hg did build for me however, so maybe we could find the appropriate change in gazebo and apply it as a patch?

Hi all. Have you tried clean-building it? @acxz I noticed you were building it with yay so this could be the issue. It does build on my machine (which doesn't necessarily mean there's nothing wrong of course ;-))

@billypilgrim: Same error like acxz's one occured by me. Could you please investigate?

I am still getting an error, build output here: https://gist.github.com/acxz/5884bd1bff5f9ba8434c09e9cf965b48

@Nim65s I've added the fix and pushed it -- thanks everyone for the help with this.

Hi,

I can confirm the issue with AutoMoc, and that the patch in the last comment fix it. @billypilgrim: could you add that patch in the PKGBUILD ?

@billypilgrim

The following patch works because it adds nothing to the changelog:

https://bitbucket.org/osrf/gazebo/commits/9d71a6134982e2bf60ce96ca97c18c956c0cc7e0/raw

I managed to install the package with this patch.

@billypilgrim Alas, no. I finally gave up and went to gazebo-hg which installed without trouble, and appears to have a version number higher than the newest version from the official site. (I didn't look deeply, but Bitbucket did not seem to have a branch for version 11.x.)

@ubuntourist Yeah I'm getting the same error. Did you manage to get it to compile with a patch?

Going directly from the git repo, without attempting to patch anything results in:

...
[ 73%] Automatic MOC for target CessnaGUIPlugin

AutoMoc subprocess error
------------------------
The moc process failed to compile
  "SRC:/plugins/CessnaGUIPlugin.hh"
into
  "SRC:/build/plugins/CessnaGUIPlugin_autogen/EWIEGA46WW/moc_CessnaGUIPlugin.cpp"

Command
-------
/usr/bin/moc -DBOOST_ALL_NO_LIB -DBOOST_DATE_TIME_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_REGEX_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DBOOST_THREAD_DYN_LINK -DCessnaGUIPlugin_EXPORTS -DHAVE_OPENGL -DLIBBULLET_VERSION=0.0 -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG "-DQT_TESTCASE_BUILDDIR=\"/home/kjcole/Downloads/gazebo/src/gazebo-10.1.0/build\"" -DQT_TESTLIB_LIB -DQT_WIDGETS_LIB -I/home/kjcole/Downloads/gazebo/src/gazebo-10.1.0/test/gtest/include -I/home/kjcole/Downloads/gazebo/src/gazebo-10.1.0/build -I/usr/include/libusb-1.0 -I/home/kjcole/Downloads/gazebo/src/gazebo-10.1.0 -I/usr/include/ignition/msgs1 -I/usr/include/ignition/transport4 -I/usr/include/ignition/fuel_tools1 -I/usr/include/ignition/common1 -I/usr/include/ignition/math4 -I/usr/include/sdformat-6.2 -I/usr/include/OGRE/RTShaderSystem -I/usr/include/OGRE -I/usr/include/OGRE/Terrain -I/usr/include/OGRE/Paging -I/usr/include/OGRE/Overlay -I/usr/include/qt -I/usr/include/qt/QtCore -I/usr/lib/qt/mkspecs/linux-g++ -I/usr/include/uuid -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui -I/usr/include/qt/QtTest -I/usr/include -I/usr/include/c++/9.2.0 -I/usr/include/c++/9.2.0/x86_64-pc-linux-gnu -I/usr/include/c++/9.2.0/backward -I/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include -I/usr/local/include -I/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed --include /home/kjcole/Downloads/gazebo/src/gazebo-10.1.0/build/plugins/CessnaGUIPlugin_autogen/moc_predefs.h -p plugins -o /home/kjcole/Downloads/gazebo/src/gazebo-10.1.0/build/plugins/CessnaGUIPlugin_autogen/EWIEGA46WW/moc_CessnaGUIPlugin.cpp /home/kjcole/Downloads/gazebo/src/gazebo-10.1.0/plugins/CessnaGUIPlugin.hh

Output
------
usr/include/tbb/tbb_profiling.:28: Parse error at "{"

make[2]: *** [plugins/CMakeFiles/CessnaGUIPlugin_autogen.dir/build.make:58: plugins/CMakeFiles/CessnaGUIPlugin_autogen] Error 1
make[1]: *** [CMakeFiles/Makefile2:12944: plugins/CMakeFiles/CessnaGUIPlugin_autogen.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

The Changelog.md fro the git clone has:

...
## Gazebo 9

## Gazebo 9.X.X (20XX-XX-XX)

1. Refactor ODE gearbox joint implementation to match hinge joint
    * [Pull request 3048](<https://bitbucket.org/osrf/gazebo/pull-request/3048>)

## Gazebo 9.8.0 (2019-XX-XX)

...

but the patch file recommended by csharpron attempts:

diff --git a/Changelog.md b/Changelog.md
--- a/Changelog.md
+++ b/Changelog.md
@@ -2,6 +2,10 @@

 ## Gazebo 9.XX.X (2019-XX-XX)

+1. Fix compilation of plugins with tbb and qt 5.14.
+    * [Pull request 3164](<https://bitbucket.org/osrf/gazebo/pull-request/3164>)
+    * [Issue #2681](<https://bitbucket.org/osrf/gazebo/issues/2681>)
+
 1. Don't pass GCC linker options to Visual Studio linker.
     * [Pull request 3153](<https://bitbucket.org/osrf/gazebo/pull-request/3153>)

I cannot find the string Gazebo 9.XX.X (2019-XX-XX) nor the string Don't pass GCC... anywhere in the Changelog.md. So, I'm not sure what it's trying to patch, but it's not trying to patch the tarball that comes with this repository.

At least, that's my naive understanding.

FWIW, I'm not very savvy with screwing around with packages, but I altered the PKGBUILD to read:

...

source=("<http://osrf-distributions.s3.amazonaws.com/>$pkgname/releases/$pkgname-$pkgver.tar.bz2"
        "fix-openal.patch::<https://bitbucket.org/shrit/gazebo/commits/556354dcebd180e0f1015b96890f9906e441b551/raw>"
        "pr-2681.patch::<https://bitbucket.org/osrf/gazebo/commits/b896424cf554e18447a7bcecb41e58163de12072/raw>")
sha256sums=('8a1fcf8697704928c9cda610a9ce81f563f211bdfb2f1fdb458193ffb36c4287'
            '4b386e845e94008102609a4fb666d698bee0480d2ce88b250dc1d849cfc93b72'
            '3ef36c590775981166d308266495c51663f0548da675d606932fdfbb9467c2e1')

prepare() {
  cd "$srcdir/$pkgname-$pkgver"
  patch --strip=1 --input=../fix-openal.patch
  patch --strip=1 --input=../pr-2681.patch
}
...

adding the URL, a SHA checksum matching the patch file created from the URL, and a patch.

PR as a result of Issue 2681 was merged.

If you need to patch it yourself before it makes it upstream, just add https://bitbucket.org/osrf/gazebo/commits/b896424cf554e18447a7bcecb41e58163de12072/raw as a patch to your PKGBUILD. It should compile and install normally afterwards.

upstream issue for OSX+fix: https://bitbucket.org/osrf/gazebo/issues/2681/moc-compilation-error-with-qt-514-tbb I am not sure though if the solution is desired, may be my sole opinion though

@acxz Yeah I'm using trizen, I'll let them know about this. Yay handles dependencies fine.

@julianoes Yep, ran into that error as well. creating an upstream issue is prob the best.

@greghab Can I ask what AUR helper you are using? In my experience quite a few AUR helpers do not properly handle dependencies, esp. considering this package. I have found success with yay. E.g. I can just do yay -Syu gazebo and the issues you mentioned do not appear for me. I know some users have had some trouble with trizen and aurutils in the past. My recommendation would be to use yay or to create a PR for whatever AUR helper you are using which fixes their dependency management.

Some changes need to be made: sdformat-6 ignition-math-4 ignition-transport-4 ignition-common-1 ignition-fuel_tools-1 ignition-msgs-1

These are no longer package versions, but separate packages in themselves.

You're also going to make the above changes to each package gazebo requires (the one's listed above), and one later dependency requires the change 'ignition-cmake-0'.

Update...: Looking at the current pkgbuild, it appears that it should be installing the above correct packages as is (I.E ignition-math-4), but for some reason I had to explicitly state them in all pkgbuilds otherwise it couldn't find the dependencies. IDK.

I'll leave this here if others are having issues, otherwise if its not corroborated ignore this.

I ran into a new error today while doing yay -Sy --rebuildtree gazebo:

AutoMoc subprocess error
------------------------
The moc process failed to compile
  "SRC:/plugins/CessnaGUIPlugin.hh"
into
  "SRC:/build/plugins/CessnaGUIPlugin_autogen/EWIEGA46WW/moc_CessnaGUIPlugin.cpp"

Command
-------
/usr/bin/moc -DBOOST_ALL_NO_LIB -DBOOST_DATE_TIME_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK -DBOOST_IOSTREAMS_DYN_LINK -DBOOST_PROGRAM_OPTIONS_DYN_LINK -DBOOST_REGEX_DYN_LINK -DBOOST_SYSTEM_DYN_LINK -DBOOST_THREAD_DYN_LINK -DCessnaGUIPlugin_EXPORTS -DHAVE_OPENGL -DLIBBULLET_VERSION=0.0 -DQT_CORE_LIB -DQT_GUI_LIB -DQT_NO_DEBUG "-DQT_TESTCASE_BUILDDIR=\"/home/julianoes/.cache/yay/gazebo/src/gazebo-10.1.0/build\"" -DQT_TESTLIB_LIB -DQT_WIDGETS_LIB -I/home/julianoes/.cache/yay/gazebo/src/gazebo-10.1.0/test/gtest/include -I/home/julianoes/.cache/yay/gazebo/src/gazebo-10.1.0/build -I/usr/include/libusb-1.0 -I/home/julianoes/.cache/yay/gazebo/src/gazebo-10.1.0 -I/usr/include/ignition/msgs1 -I/usr/include/ignition/transport4 -I/usr/include/ignition/fuel_tools1 -I/usr/include/ignition/common1 -I/usr/include/ignition/math4 -I/usr/include/sdformat-6.2 -I/usr/include/OGRE/RTShaderSystem -I/usr/include/OGRE -I/usr/include/OGRE/Terrain -I/usr/include/OGRE/Paging -I/usr/include/OGRE/Overlay -I/usr/include/qt -I/usr/include/qt/QtCore -I/usr/lib/qt/mkspecs/linux-g++ -I/usr/include/uuid -I/usr/include/qt/QtWidgets -I/usr/include/qt/QtGui -I/usr/include/qt/QtTest -I/usr/include -I/usr/include/c++/9.2.0 -I/usr/include/c++/9.2.0/x86_64-pc-linux-gnu -I/usr/include/c++/9.2.0/backward -I/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include -I/usr/local/include -I/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include-fixed --include /home/julianoes/.cache/yay/gazebo/src/gazebo-10.1.0/build/plugins/CessnaGUIPlugin_autogen/moc_predefs.h -p plugins -o /home/julianoes/.cache/yay/gazebo/src/gazebo-10.1.0/build/plugins/CessnaGUIPlugin_autogen/EWIEGA46WW/moc_CessnaGUIPlugin.cpp /home/julianoes/.cache/yay/gazebo/src/gazebo-10.1.0/plugins/CessnaGUIPlugin.hh

Output
------
usr/include/tbb/tbb_profiling.:28: Parse error at "{"

make[2]: *** [plugins/CMakeFiles/CessnaGUIPlugin_autogen.dir/build.make:58: plugins/CMakeFiles/CessnaGUIPlugin_autogen] Error 1
make[1]: *** [CMakeFiles/Makefile2:8558: plugins/CMakeFiles/CessnaGUIPlugin_autogen.dir/all] Error 2

I have no idea how to debug this, any hints?

@lucasmazz what is the output of yay -Ss ignition-msgs and yay -Ss ignition-transport?

Maybe try uninstalling all of the ignition-* deps of gazebo and then do a clean build of gazebo via yay?

@billypilgrim Ayy you added the versioned deps for the ign* pacakges! Thx so much!

Hi, I'm getting this error when I try to install gazebo from yay:

-- BUILD ERRORS: These must be resolved before compiling.
--      Missing: Ignition msgs1 library (libignition-msgs-dev).
--      Missing: Ignition Transport (libignition-transport4-dev)
-- END BUILD ERRORS

But I've already installed those libs.

graphviz is an additional dependency. Gazebo requires libcdt.so.5

The maintainer over at ignition-cmake @acxz reminded me in https://aur.archlinux.org/packages/ignition-cmake/#comment-713109 that ignition-cmake is not required for gazebo. Still in the PKGBUILD file of this AUR there's the line makedepends=('cmake' 'doxygen' 'ignition-cmake'). I just wanted to give a hint since this dependency might not be necessary (I didn't test it).

@acxz fixed the issue by some changes in the igntion-cmake AUR. Thanks again! More info see https://aur.archlinux.org/packages/ignition-cmake/#comment-712301

Thanks for all the answers, the nproc one is a nice hint, I was used to grepping /proc/cpuinfo since it works even without that binary e.g. on Android CLI.

I still have the issue on latest Manjaro fresh install: yay -S gazebo --noconfirm fails with

[ 47%] Built target component_deps_RelWithDebInfo
[ 47%] Performing test step for 'component_deps_Release'
[ 47%] Completed 'component_deps_Release'
[ 47%] Built target component_deps_Release
make: *** [Makefile:141: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...
Error making: ignition-cmake

I am totally aware that adjusting the PKGBUILD is a hack but I don't know any way of telling CMake to disable build testing for ignition-cmake (-DBUILD_TESTING=OFF) from the file /etc/makepkg.conf. Setting the environmental variable BUILD_TESTING=OFF in the configuration doesn't help. It doesn't belong into any of CFLAGS/CXXFLAGS/LDFLAGS according to my understanding and also in the linked (wiki)[https://wiki.archlinux.org/index.php/Makepkg#Troubleshooting] it says if -DCMAKE_BUILD_TYPE is defined for a certain package it will ignore the /etc/makepkg.conf CMake configuration.

Would be nice if the root cause could actually get fixed since the ignition-cmake PKGBUILD defines ENABLE_TESTS_COMPILATION:BOOL=False and then CMake out put tells you that parameter doesn't exist but you need to disable testing (which ENABLE_TESTS_COMPILATION:BOOL=False previously probably did) to make the build work on Arch.

I'll also comment on the ignition-cmake AUR.

...but you should put your makeflags in /etc/makepkg.conf rather than hacking the PKGBUILD.

@MaEtUgR, instead of grepping /proc/cpuinfo you can just use the nproc command (ex MAKEFLAGS="-j$(nproc)"). See the wiki.

Hmm I haven't run into the issue you seem to have with building the tests but I'll investigate it later.

In terms of the make flags, you can just set those in /etc/makepkg.conf instead.

Hi, first of all thanks a lot for providing this AUR. I did quite some tests on latest Manjaro and got it working within a reasonable compilation timeframe using:

# enable multicore gazebo compilation
sudo sed -i '/MAKEFLAGS=/c\MAKEFLAGS="-j'$(($(grep -c processor /proc/cpuinfo)+2))'"' /etc/makepkg.conf

# install gazebo from AUR
yay -S gazebo --noconfirm

# fix incompatible compile flag to disable default testing that leads to build error
# see https://bitbucket.org/ignitionrobotics/ign-cmake/issues/62/compilation-failing-when-performing
pushd ~/.cache/yay/ignition-cmake/
sed -i 's/-DENABLE_TESTS_COMPILATION:BOOL=False/-DBUILD_TESTING=OFF/g' PKGBUILD
makepkg -si --noconfirm
popd

# continue installing gezebo
yay -S gazebo --noconfirm

Is it possible to automate especially the ignition-cmake fix but also the multicore compilation such that the next user doesn't need to spend as much time as me? Am I doing something wrong such that these manual modifications are necessary? Can I contribute other than writing a comment here? Can I submit a patch?

@billypilgram: I apologize for my eagerness during the past. I understand your point on versioned dependencies, I concede. But for ignition-common/fuel-tools/msgs/cmake the version deps do matter. http://gazebosim.org/tutorials?tut=install_dependencies_from_source&cat=install Users are prone to installing 4 extra packages that are not needed for this package.

However, I will stop bothering you on this issue. Thank you for taking the time to respond.

I don't really see the point tbh. As an AUR maintainer all I care about is: a) Does it build for all real (not hypothetical) users? b) Is it up to date?

And I try to deal with the above in a relatively timely manner. You're asking me to tailor the PKGBUILD to your tastes in a way which will have no impact on any users.

I don't want to co-maintain this package with you because you don't seem to understand what is required of AUR maintainers and what the requirements for a PKGBUILD are: 1) You seem to think packages should be orphaned if the maintainer does not respond within 24 hours (they don't, as per the wiki) 2) The versioned dependencies are not unnecessary as presumably older versions of these packages won't work and, moreover, removing the version dependency will have no effect whatsoever on any users

You can maintain your packages however you like, but I only care about a) and b), as seemingly do all the other users I've encountered on the AUR. Caring about anything else is really just a waste of everyone's time, especially non-functional changes to PKGBUILDs.

@billypilgram If you could remove the unnecessary pkgver dependencies and add the necessary ones (see comments below) that would be much appreciated. I would be willing to co-maintain this package with you to fix these issues.

@lucasmazz Are you having trouble with the sdformat package? If so I recommend posting the issue there. The PKGBUILD for this package does not compile unit tests, unless they are happening with the default make command. In that case I would recommend opening an issue to gazebo upstream.

@zigas Here is the relevant bug: https://bugs.archlinux.org/task/61461?project=5&string=libpgm. As you can see the libpgm package is out of date on the official repos. Instead of manually editing files (not recommended), you can use the libpgm-git package instead, which is a newer version that does not have that issue.

Hello, I'm having some problems with sdformat. Looks like some tests fails when installing this package:

23 - INTEGRATION_locale_fix (Failed), 81 - UNIT_ign_TEST (Failed)

This is an issue with the libpgm package (which I can't seem to find on the bugtracker right now).

The way to fix it is to remove the non-existent path from /usr/lib/pkgconfig/openpgm-5.2.pc.

Hi, I'm having problems installing this package, this is the error pamac gives when installing ignition-transport 4: "CMake Error in src/CMakeLists.txt: Imported target "ZeroMQ::ZeroMQ" includes non-existent path "/usr/lib/pgm-5.2/include" in its INTERFACE_INCLUDE_DIRECTORIES."

@acxz thanks for letting me know. Hopefully upstream will fix this at some point.

Posting this github issue here since it relates to this PKGBUILD. https://github.com/ros-melodic-arch/ros-melodic-desktop-full/issues/2

@billypilgrim The source installation page for Gazebo (http://gazebosim.org/tutorials?tut=install_dependencies_from_source&cat=install) states that the following dependencies have to be a specific version:

sdformat=6 ignition-common=1 ignition-fuel-tools=1 ignition-math=4 ignition-transport=4 ignition-msgs=1 ignition-cmake=0

As of right now, only ignition-math/transport and sdformat are specified. If the others can be specified that would prevent users from downloading unnecessary higher versioned ignition packages.

The thing with packages like libtar, libccd, etc. is that there is no package in the official repos or the AUR that offers any version below the specified version. Therefore there is no need to specify versioned dependencies for those packages, it is redundant. Any package of libtar you can get will be versioned >= 1.2.

@acxz is right that you do need specific versions of these dependencies. There's an upstream issue with their build system: https://bitbucket.org/osrf/gazebo/issues/2638/gazebo-source-build-error

I assume that whoever put in the specific versions of libtar and curl that are needed did so because Gazebo won't work with older versions.

@Morganamilo I am 100% sure (you can go ahead and try building it yourself if you do not believe me).

I do agree with you on the second point tho. The version dependencies of libtar>=1.2 and curl>=4 are completely unnecessary and should be removed.

@acxz are you totally sure?

If this package truly requires sdformat=6 and say, not 5 or 7, then that's fair enough.

But arch's general policy is to not over use versioned depends. There's no need to specify stuff like libtar>=1.2 and curl>=4. And your total over use of versioned depends leads me to assume sdformat=6 is also unneeded.

@Morganamilo Versioned depends are needed for this package, since the package does not build with other versions of that dependency. Would there be a better way?

Please avoid using versioned depends.

I had two issues spawning models via roslaunch in gazebo. The fisrt was;

Traceback (most recent call last):
  File "/opt/ros/melodic/lib/gazebo_ros/spawn_model", line 25, in <module>
    from urlparse import urlsplit, SplitResult
ModuleNotFoundError: No module named 'urlparse'

I fixed it with:

sudo sed -i.bak 's/urlparse/urllib.parse/' /opt/ros/melodic/lib/gazebo_ros/spawn_model

The second appeared after I fixed the first one and was:

  File "/opt/ros/melodic/lib/python3.7/site-packages/gazebo_msgs/srv/_SpawnModel.py", line 103, in serialize
    _x = _x.encode('utf-8')
AttributeError: 'bytes' object has no attribute 'encode'

I fixed it with:

sudo sed -i.bak 's/python3 or type(_x) == unicode/type(_x) == str/' /opt/ros/melodic/lib/python3.7/site-packages/gazebo_msgs/srv/_SpawnModel.py

@acxz could you post what exactly you changed? I changed the dependencies in the gazebo PKGBUILD like you can see below and I still get the same error:

depends=('boost>=1.40.0' 'curl>=4.0' 'freeglut' 'freeimage>=3.0'
         'intel-tbb>=3.0' 'libccd>=1.4' 'libltdl>=2.4.2' 'libtar>=1.2' 'libxml2>=2.7.7'
         'ogre-1.9' 'protobuf>=2.3.0' 'sdformat=8.2.0' 'ignition-math=6.2.0' 'ignition-transport=7.0.0'
         'ignition-common' 'ignition-fuel_tools' 'ignition-msgs=4.2.0' 'tinyxml2' 'qwt')

@billypilgrim I am also getting the same error as @astier. Can this package be fixed so that it works?

It seems as tho the fix is simply specifying the version numbers for dependent packages, i.e. ignition-transport=4 instead of ignition-transport>=4

-- BUILD ERRORS: These must be resolved before compiling.
--      Missing: SDF version >=6. Required for reading and writing SDF files.
--      Missing: Ignition msgs1 library (libignition-msgs-dev).
--      Missing: Ignition math (libignition-math4-dev)
--      Missing: Ignition Transport (libignition-transport4-dev)
-- END BUILD ERRORS

ignition-transport, ignition-math, etc. are installed however.

Hi,

I think this package is missing a dependency on urdfdom, as I got the following error during compilation, and installing it solved the issue: 

[ 67%] Linking CXX executable gzserver /usr/bin/ld: warning: liburdfdom_sensor.so.1.0, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../lib/libsdformat.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: liburdfdom_model_state.so.1.0, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../lib/libsdformat.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: liburdfdom_model.so.1.0, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../lib/libsdformat.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: liburdfdom_world.so.1.0, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../lib/libsdformat.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/../../../../lib/libsdformat.so: undefined reference to `urdf::parseURDF(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)' collect2: error: ld a retourné le statut de sortie 1

Yes, of course. Sorry busy day.

It still doesn't build because the source directory needs to be updated. I used this patch to make it a little cleaner: https://gist.github.com/lopsided98/7ea7b599281b6dea4552f5dfafe2ac3c

I tested this and it now builds correctly.

Right :D fixed!

Thanks for the fix, but you forgot to update sha256sums when you updated to 9.6.0.

Fixed that

Thanks! Will fix that later today

This package does not build in a clean chroot because it is missing ignition-cmake as a makedepends.

It works, thank you very much!

I have changed the build to use OGRE-1.9 (Ubuntu and macOS builds both use this version).

PS: tinyxml2 updated so make sure ignition-common and libdart (optional) have been rebuilt against that if you are having issues starting gazebo.

After starting Gazebo, it instantly crashes. By using --verbose it seems that I have nearly the same problem like @teiesti. I've tried the solution of @nicolino out, but unfortunately I cannot find the right line or it does not work here. Also I'm wondering about the odd double messaging at the beginning of the startup of Gazebo in the terminal.

Gazebo multi-robot simulator, version 9.4.1
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org

[Msg] Waiting for master.
Gazebo multi-robot simulator, version 9.4.1
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org

[Msg] Waiting for master.
[Msg] Connected to gazebo master @ http://127.0.0.1:11345
[Msg] Publicized address: 172.18.91.212
[Msg] Connected to gazebo master @ http://127.0.0.1:11345
[Msg] Publicized address: 172.18.91.212
[Wrn] [Event.cc:61] Warning: Deleting a connection right after creation. Make sure to save the ConnectionPtr from a Connect call
[Wrn] [GuiIface.cc:120] Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.

[Err] [main.cc:34] Ogre Error:ItemIdentityException: Can not find codec for 'png' image format.
Supported formats are: dds ktx pkm. in Codec::getCodec at /build/ogre/src/ogre-1.11.2/OgreMain/src/OgreCodec.cpp (line 66)
[Wrn] [ModelDatabase.cc:212] Unable to connect to model database using [http://models.gazebosim.org/apartment/model.config]. Only locally installed models will be available.
[Err] [ModelDatabase.cc:394] Unable to get model name[http://models.gazebosim.org/apartment]
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = gzclient-9.4.1 path = /usr/bin pid = 4197
KCrash: Arguments: /usr/bin/gzclient-9.4.1 
KCrash: Attempting to start /usr/lib/drkonqi from kdeinit
sock_file=/run/user/1000/kdeinit5__0
Unable to start Dr. Konqi
Re-raising signal for core dump handling.
[Wrn] [Publisher.cc:141] Queue limit reached for topic /gazebo/default/physics/contacts, deleting message. This warning is printed only once.

Thanks for help.

i've try to compile from https://bitbucket.org/osrf/gazebo/get/gazebo9_9.4.1.tar.bz2

i've install boost libray and runtime but when i try to "make" it, error at 10%. the error :

#include <boost/uuid/sha1.hpp> file not found.

in last boost version, https://www.archlinux.org/packages/extra/x86_64/boost/ (check package detail) it appears sha1 is in detail folder (usr/include/boost/uuid/detail/sha1.hpp), so i've edit the file for

#include <boost/uuid/detail/sha1.hpp>

"make" again and now compile (i wait for news)

@Teasp00n I don't have much time to look into this at the moment. I've added you as a co-mantainer. Hope you can do it! :)

Both the Ubuntu package and homebrew formula use OGRE-1.9 so I modified the PKGBUILD to use that instead of just any ogre.

Currently the AUR ogre-1.9 package installs to /opt/OGRE-1.9 which means we need to add export PKG_CONFIG_PATH="/opt/OGRE-1.9/lib/pkgconfig:$PKG_CONFIG_PATH" before the cmake call in the build() block. You also should not apply the ogre-1.11.patch so remove that from the prepare() block.

NOTE: I needed to add the PKG_CONFIG_PATH for ros-melodic-gazebo-plugins when subsequently building that.

@nicolino Your patch works great if I apply it to gazebo/rendering/RenderEngine.cc. I believe You wanted to suggest that I patch that file (I had to grep -R it!). Thanks a lot!

@GPereira Is it possible to integrate the patch into Your package to make it work out of the box?

@telesti patch the code with this. It is an old patch that slipped through.

Check everything before.

@@ -425,6 +425,11 @@
 +#if (OGRE_VERSION >= ((1 << 16) | (11 << 8) | 0))
 +    plugins.push_back(path+"/Codec_EXR");
 +    plugins.push_back(path+"/Codec_FreeImage");
 +#endif
 +
      plugins.push_back(path+"/RenderSystem_GL");
      plugins.push_back(path+"/Plugin_ParticleFX");
      plugins.push_back(path+"/Plugin_BSPSceneManager");
 @@ -798,8 +803,10 @@

As of today, gazebo compiles but segfaults on startup:

$ gazebo --verbose
Gazebo multi-robot simulator, version 9.4.1
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org

[Msg] Waiting for master.
[Msg] Connected to gazebo master @ http://127.0.0.1:11345
[Msg] Publicized address: 192.168.1.124
Gazebo multi-robot simulator, version 9.4.1
Copyright (C) 2012 Open Source Robotics Foundation.
Released under the Apache 2 License.
http://gazebosim.org

[Msg] Waiting for master.
[Msg] Connected to gazebo master @ http://127.0.0.1:11345
[Msg] Publicized address: 192.168.1.124
[Wrn] [Event.cc:61] Warning: Deleting a connection right after creation. Make sure to save the ConnectionPtr from a Connect call
[Wrn] [GuiIface.cc:120] Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
If that is not possible, in Qt 5 you must at least reimplement
QCoreApplication::notify() and catch all exceptions there.

[Err] [main.cc:34] Ogre Error:ItemIdentityException: Can not find codec for 'png' image format.
Supported formats are: dds ktx pkm. in Codec::getCodec at /build/ogre/src/ogre-1.11.2/OgreMain/src/OgreCodec.cpp (line 66)
[Wrn] [Publisher.cc:141] Queue limit reached for topic /gazebo/default/physics/contacts, deleting message. This warning is printed only once.

Is there something I can do about this?

It's fixed! ;)

Sorry I've downgraded by mistake. I did a quick fix to address your concern about the installation. Now that I am free I can patch the file. Take it easy please.

Now you've made the problem worse. You downgraded the version of the package while still not fixing the compilation error.

As I said, Patch the source code to fix the header include path.

Don't violate the user's Arch Linux installation. Patch the source code to fix the header include path. Ideally, submit this as an upstream pull request so it will be fixed for everyone. (You can #ifdef this so the upstream code will do boost version checks and select the right header.)

This PKGBUILD currently violates AUR packaging guidelines.

-- your friendly neighborhood TU

thanks! Updated and fixed version

@portaloffreedom I think the header just moved. I was able to symlink it and it is currently building successfully (at about 70% now):

sudo ln -s /usr/include/boost/uuid/detail/sha1.hpp /usr/include/boost/uuid/sha1.hpp

On an archlinux fresh install it fails to compile because of some deprecated boost header that got removed:

In file included from ~/.cache/aurman/gazebo/src/osrf-gazebo-5714795a2e79/gazebo/common/BVHLoader.cc:27:
~/.cache/aurman/gazebo/src/osrf-gazebo-5714795a2e79/gazebo/common/CommonIface.hh:22:10: fatal error: boost/uuid/sha1.hpp: No such file or directory
 #include <boost/uuid/sha1.hpp>
          ^~~~~~~~~~~~~~~~~~~~~

The header is now at <boost/uuid/detail/sha1.hpp>

See also https://www.boost.org/doc/libs/1_67_0/boost/uuid/sha1.hpp

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?

@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?

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).

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

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

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

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.

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

So is it possible to put nicolino patch in build ?

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.

Thanks nodabba,

now Gazebo compile and runs with latest boost and ogre.

This part:

diff -ruN original/gazebo-9.0.0/gazebo/rendering/RenderEngine.cc 
patched/gazebo-9.0.0/gazebo/rendering/RenderEngine.cc
--- original/gazebo-9.0.0/gazebo/rendering/RenderEngine.cc      2018-01-25 23:25:48.000000000 +0100
+++ patched/gazebo-9.0.0/gazebo/rendering/RenderEngine.cc       2018-06-02 21:21:19.426983596 +0200

@@ -425,6 +425,11 @@
     std::string extension = ".so";
 #endif

+#if (OGRE_VERSION >= ((1 << 16) | (11 << 8) | 0))
+    plugins.push_back(path+"/Codec_EXR");
+    plugins.push_back(path+"/Codec_FreeImage");
+#endif
+
     plugins.push_back(path+"/RenderSystem_GL");
     plugins.push_back(path+"/Plugin_ParticleFX");
     plugins.push_back(path+"/Plugin_BSPSceneManager");

did the trick.

Best Regards

I was able to compile and run gazebo with the following modified ogre-1.11.patch: https://gist.github.com/n0dabba/bd586b466da068e2eb9a24c003d507c1 Current patch was lacking of one more fix (see https://bitbucket.org/osrf/gazebo/issues/2475/gazebo9-compile-error-with-ogre111 for more info). Thanks @greboide for link.

Hi,

Last version of gazebo fixes newer boost dependencies and, supposedly, OGRE.

However, whenever I try to run it, the following happens:

[Err] [main.cc:34] Ogre Error:ItemIdentityException: Can not find codec for 'png' image format. Supported formats are: dds ktx pkm. in Codec::getCodec at /build/ogre/src/ogre-1.11.1/OgreMain/src/OgreCodec.cpp (line 66)

I have checked on google and the same problem is reported here:

https://forums.ogre3d.org/viewtopic.php?t=94306

It says to modify a plugins.cfg as new version of Ogre needs explicit activation of the png images plugin.

Although I found the plugins.cfg file for the general Ogre installation, I could not find the gazebo one.

Any clues?

Best Regards.

Hi,

for the same problems with Ogre and boost, also the installation of ros-melodic-gazebo-ros goes nuts.

@LazyLucretia

I have installed and test-run (just roscore for now) ROS-MELODIC AND GAZEBO by keeping the old downgrades

Ogre: ogre-1.10.10-3-x86_64.pkg.tar.xz boost: boost-1.66.0-3-x86_64.pkg.tar.xz boost-libs: boost-libs-1.66.0-3-x86_64.pkg.tar.xz

and also downgrading

gdbm to gdbm-1.14.1-1-x86_64.pkg.tar.xz

@jlecoeur

Yep, libreoffice needs newer boost.

Best regards

@greboide It does compile, but doesn't run!!

i was able to compile with this PKGBUILD: https://gist.github.com/greboide/2949ae90ab6a23a9c541086439f1533a ive used patchs from here: https://bitbucket.org/osrf/gazebo/issues/2475/gazebo9-compile-error-with-ogre111 but i did not tested it to see if it is working...

@LazyLucretia comment "patch -Np2 -i "${srcdir}/ogre-1.10.patch" in PKGBUILD

Same here, I have downgraded boost as indicated by @nicolino as a temporary fix. An annoying side effect is that libre office now crashes on startup.

A proper fix would be really appreciated!

@LazyLucretia I am having the same issue. Still waiting for a proper fix

@rochus I tried your patch. Unfortunately, it did not work for me. I get this error when I try to build:

In file included from /home/umut/.manually_installed_pkgs/gazebo/src/gazebo-9.0.0/gazebo/rendering/MovableText.hh:27,
                 from /home/umut/.manually_installed_pkgs/gazebo/src/gazebo-9.0.0/gazebo/rendering/ApplyWrenchVisual.cc:24:
/home/umut/.manually_installed_pkgs/gazebo/src/gazebo-9.0.0/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:2501: gazebo/rendering/CMakeFiles/gazebo_rendering.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

@LazyLucretia, the compilation errors are due to boost 1.67. Upstream gazebo already fixed these issues in their master branch. You can find my patch in which I backported the relevant changes for the AUR package here: https://gist.github.com/rochus/82ab183cbbebe91ca427e29a28fa3b77

@nicolino Your suggested workaround indeed lets gazebo build. However, I (probably like many other robotics researcher) was trying to install the ros-melodic-desktop-full package which includes gazebo. Unfortunately, downgrading ogre, boost and boost-libs breaks dependencies for ros-melodic-diff-drive-controller which is also a part of ros-melodic-desktop-full package.

Hi,

I have found a workaround to make it compile and run. I will restrain to make any personal comment, but it is easy to understand where the problem lies.

I have managed to make it work with a combination of luck and downgrade.

Simply downgrade ogre and the combination of boost and boost-libs to the following versions:

Ogre: ogre-1.10.10-3-x86_64.pkg.tar.xz boost: boost-1.66.0-3-x86_64.pkg.tar.xz boost-libs: boost-libs-1.66.0-3-x86_64.pkg.tar.xz

It then works without any patch.

OF COURSE IT BREAKS BOOST DEPENDENCIES but if you are reading this it means you work with Gazebo, and it is probably a research project and you can handle, for a while, this stuff.

Best Regards

Currently, build fails on my machine with this error message:

[ 14%] Building CXX object gazebo/common/CMakeFiles/gazebo_common.dir/Console.cc.o
/home/umut/.cache/aurman/gazebo/src/gazebo-9.0.0/gazebo/common/Console.cc: In member function ‘void gazebo::common::FileLogger::Init(const string&, const string&)’:
/home/umut/.cache/aurman/gazebo/src/gazebo-9.0.0/gazebo/common/Console.cc:197:12: error: no match for ‘operator==’ (operand types are ‘boost::system::error_code’ and ‘int’)
     if (ec == 0)
         ~~~^~~~
/home/umut/.cache/aurman/gazebo/src/gazebo-9.0.0/gazebo/common/Console.cc:197:12: note: candidate: ‘operator==(int, int)’ <built-in>
/home/umut/.cache/aurman/gazebo/src/gazebo-9.0.0/gazebo/common/Console.cc:197:12: note:   no known conversion for argument 1 from ‘boost::system::error_code’ to ‘int’
In file included from /usr/include/boost/filesystem/path_traits.hpp:23,
                 from /usr/include/boost/filesystem/path.hpp:25,
                 from /usr/include/boost/filesystem.hpp:16,
                 from /home/umut/.cache/aurman/gazebo/src/gazebo-9.0.0/gazebo/common/Console.cc:18:
/usr/include/boost/system/error_code.hpp:611:17: note: candidate: ‘bool boost::system::operator==(const boost::system::error_code&, const boost::system::error_condition&)’
     inline bool operator==( const error_code & code,
                 ^~~~~~~~
/usr/include/boost/system/error_code.hpp:611:17: note:   no known conversion for argument 2 from ‘int’ to ‘const boost::system::error_condition&’
/usr/include/boost/system/error_code.hpp:624:17: note: candidate: ‘bool boost::system::operator==(const boost::system::error_condition&, const boost::system::error_code&)’
     inline bool operator==( const error_condition & condition,
                 ^~~~~~~~
/usr/include/boost/system/error_code.hpp:624:17: note:   no known conversion for argument 1 from ‘boost::system::error_code’ to ‘const boost::system::error_condition&’
/usr/include/boost/system/error_code.hpp:526:26: note: candidate: ‘bool boost::system::operator==(const boost::system::error_code&, const boost::system::error_code&)’
       inline friend bool operator==( const error_code & lhs,
                          ^~~~~~~~
/usr/include/boost/system/error_code.hpp:526:26: note:   no known conversion for argument 2 from ‘int’ to ‘const boost::system::error_code&’
make[2]: *** [gazebo/common/CMakeFiles/gazebo_common.dir/build.make:193: gazebo/common/CMakeFiles/gazebo_common.dir/Console.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1544: gazebo/common/CMakeFiles/gazebo_common.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
==> ERROR: A failure occurred in build().
    Aborting...

@GPereira Could you put patches, please?

@rochus Tried to compile on Arch Linux with your patch today. Found out that Gazebo still needs one patch in gazebo/rendering/RenderEngine.cc at line 427:

+++
#if (OGRE_VERSION >= ((1 << 16) | (11 << 8) | 0))
    plugins.push_back(path+"/Codec_EXR");
    plugins.push_back(path+"/Codec_FreeImage");
#endif

    plugins.push_back(path+"/RenderSystem_GL");
    plugins.push_back(path+"/Plugin_ParticleFX");
    plugins.push_back(path+"/Plugin_BSPSceneManager");
    plugins.push_back(path+"/Plugin_OctreeSceneManager");

Plus you need to use asp export ogre to get the PKGBUILD of Ogre 1.11 and change the cmake options:

  cmake .. \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DOGRE_BUILD_DEPENDENCIES=FALSE \
    -DCMAKE_BUILD_TYPE=RelWithDebInfo \
    -DOpenGL_GL_PREFERENCE=GLVND \
    -DOGRE_BUILD_PLUGIN_FREEIMAGE=TRUE

Confirmed that Gazebo 9.0.0 works seamlessly after these patches.

GPereira, I believe that ogre and ogre3d are the same. It appears that aur/ogre3d is ogre locked to version 1.10.11, the other ogre packages have their corresponding version number in the package name (e.g. aur/ogre-1.8, aur/ogre1.9, etc.).

The issue with gazebo and ogre is, that ogre 1.11 introduced several API breaking changes. I tried to follow all the changes in the ogre documentation and apply them to gazebo. I came up with the following PKGBUILD and patch file, with which gazebo compiles fine (excepted for a vast list of deprecation warnings, which I ignored). I didn't have any time yet to test if the compiled version runs fine at all, I was merely interested in compiling it.

PKGBUILD: https://gist.github.com/rochus/547b26bc85a39195e3d1833280798855 ogre-1.11.patch: https://gist.github.com/rochus/003b156bcc8368c8c353be12b748986e gazebo issue: https://bitbucket.org/osrf/gazebo/issues/2475/gazebo9-compile-error-with-ogre111

Nimoab, is ogre being replaced for ogre3d? is that it? Their website leads to that conclusion but I am not so sure

@al3xst I solved that problem by installing the AUR ogre3d package (https://aur.archlinux.org/packages/ogre3d/) and modifying the dependency in the gazebo's PKGBUILD. Also, the ogre3d package had to be compiled without the C++11 support. After rebuilding everythin, I also had a shadow issue. In the end I solved my problem compiling the ogre3d package with these options (don't know if they're all necessary though, especially TESTS and SAMPLES are certainly not, but I wanted to make sure Ogre was working properly before compiling gazebo):

cmake -G"Unix Makefiles" \
        -DOpenGL_GL_PREFERENCE="GLVND" \
        -DOGRE_BUILD_SAMPLES=ON \
        -DOGRE_BUILD_DEPENDENCIES=OFF \
        -DOGRE_BUILD_TESTS=ON \
        -DOGRE_BUILD_COMPONENT_RTSHADERSYSTEM=ON \
        -DOGRE_BUILD_COMPONENT_VOLUME=ON \
        -DOGRE_BUILD_TOOLS=ON \
        -DOGRE_CONFIG_DOUBLE=OFF \
        -DOGRE_INSTALL_SAMPLES=OFF \
        -DOGRE_CONFIG_THREAD_PROVIDER=std \
        -DOGRE_USE_STD11=OFF \
        -DCMAKE_INSTALL_PREFIX=/usr \
        "../${_pkgname}-$pkgver/"

ffmpeg also got updated this morning and I had a similar problem, but with libavcodec.so.57. I coudln't rebuild the gazebo package this time because the name of some constant changed in avcodec.

To rebuild gazebo, I had to patch and rebuild the package ignition-common first, then I could patch and rebuild gazebo

Here are the patches I made:

• gazebo: https://pastebin.com/5b2zzYAz
• ignition-common: https://pastebin.com/Gsqi6J6R

Hope it helps.

ogre got updated to version 1.11 but gazebo tries to load explicitly version 1.10.11 of all ogre libraries, so gazebo fails to start right now.

Interesting. Thanks for the feedback.

@racko, it seem missing the dependence of gxlinfo or python-opengl package in my machine, so after I installed the package listed before, gazebo could be installed successfully.

But I can't reproduce the problem after I remove the gxlinfo & python-opengl and reinstall gazebo package.

Check https://bitbucket.org/osrf/gazebo/issues/2059/fail-to-build-current-gazebo-git for more detail discuss.

Could you check the terminal output? I fear that CMakeError.log is not helping. I find

Determining if the function pthread_create exists in the pthread passed with the following output:

in CMakeOutput.log and

Determining if the pthread_create exist failed with the following output:

in CMakeError.log after a successful build.

Hello,

Thanks for mantaining this package!

I try to use yaourt to install this package, but fall through minor issues when build gazebo.

The CMakeError.log as follows

Determining if the pthread_create exist failed with the following output:

Change Dir: /tmp/yaourt-tmp-lennon/aur-gazebo/src/gazebo-9.0.0/build/CMakeFiles/CMakeTmp

Run Build Command:"/usr/bin/make" "cmTC_18ece/fast"

/usr/bin/make -f CMakeFiles/cmTC_18ece.dir/build.make CMakeFiles/cmTC_18ece.dir/build

make[1]: Entering directory '/tmp/yaourt-tmp-lennon/aur-gazebo/src/gazebo-9.0.0/build/CMakeFiles/CMakeTmp'

Building C object CMakeFiles/cmTC_18ece.dir/CheckSymbolExists.c.o

/usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -o CMakeFiles/cmTC_18ece.dir/CheckSymbolExists.c.o -c /tmp/yaourt-tmp-lennon/aur-gazebo/src/gazebo-9.0.0/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c

Linking C executable cmTC_18ece

/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_18ece.dir/link.txt --verbose=1

/usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -rdynamic CMakeFiles/cmTC_18ece.dir/CheckSymbolExists.c.o -o cmTC_18ece

CMakeFiles/cmTC_18ece.dir/CheckSymbolExists.c.o: In function `main':

CheckSymbolExists.c:(.text.startup+0x3): undefined reference to `pthread_create'

collect2: error: ld returned 1 exit status

make[1]: *** [CMakeFiles/cmTC_18ece.dir/build.make:98: cmTC_18ece] Error 1

make[1]: Leaving directory '/tmp/yaourt-tmp-lennon/aur-gazebo/src/gazebo-9.0.0/build/CMakeFiles/CMakeTmp'

make: *** [Makefile:126: cmTC_18ece/fast] Error 2

File /tmp/yaourt-tmp-lennon/aur-gazebo/src/gazebo-9.0.0/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c: / /

include <pthread.h></pthread.h>

int main(int argc, char** argv) { (void)argv;

ifndef pthread_create

return ((int*)(&pthread_create))[argc];

else

(void)argc; return 0;

endif

CheckSymbolExists.c:(.text+0x1b): undefined reference to `pthread_create'

I guess add flag or find_package(Threads) in the CMakeLists.txt in the src directory should fix the problem, but it doesn't.

Is there someway to solve this issue. I have no idea how to search it by google now.

Best regards,

lennon

@GPereira that is the tipical sign that a rebuild is needed

it throws this error when executing "gazebo" on terminal: gazebo: error while loading shared libraries: libconsole_bridge.so.0.3: cannot open shared object file: No such file or directory

However the package "console_bridge" is installed

Fixed.

Wow, how stupid of me: I created a patch but forgot to commit and push it ... give me a few minutes ...

Hi, the flollowing errors occur when building gazebo/rendering/CMakeFiles/gazebo_rendering.dir/CustomPSSMShadowCameraSetup.cc.o

/tmp/yaourt-tmp-arithemetica/aur-gazebo/src/gazebo-9.0.0/gazebo/rendering/CustomPSSMShadowCameraSetup.cc: In member function 'virtual bool gazebo::rendering::CustomPSSM3::resolveParameters(Ogre::RTShader::ProgramSet)': /tmp/yaourt-tmp-arithemetica/aur-gazebo/src/gazebo-9.0.0/gazebo/rendering/CustomPSSMShadowCameraSetup.cc:69:47: error: invalid use of incomplete type 'class Ogre::RTShader::Program' Ogre::RTShader::Function vsMain = vsProgram->getEntryPointFunction();

In file included from /usr/include/OGRE/RTShaderSystem/OgreShaderProgramManager.h:30:0, from /usr/include/OGRE/RTShaderSystem/OgreRTShaderSystem.h:30, from /tmp/yaourt-tmp-arithemetica/aur-gazebo/src/gazebo-9.0.0/gazebo/rendering/ogre_gazebo.h:67, from /tmp/yaourt-tmp-arithemetica/aur-gazebo/src/gazebo-9.0.0/gazebo/rendering/CustomPSSMShadowCameraSetup.hh:21, from /tmp/yaourt-tmp-arithemetica/aur-gazebo/src/gazebo-9.0.0/gazebo/rendering/CustomPSSMShadowCameraSetup.cc:50:

/usr/include/OGRE/RTShaderSystem/OgreShaderPrerequisites.h:61:7: note: forward declaration of 'class Ogre::RTShader::Program' class Program;

/tmp/yaourt-tmp-arithemetica/aur-gazebo/src/gazebo-9.0.0/gazebo/rendering/CustomPSSMShadowCameraSetup.cc:73:20: error: invalid use of incomplete type 'class Ogre::RTShader::Function' mVSInPos = vsMain->getParameterBySemantic(vsMain->getInputParameters(),

In file included from /usr/include/OGRE/RTShaderSystem/OgreShaderProgramManager.h:30:0, from /usr/include/OGRE/RTShaderSystem/OgreRTShaderSystem.h:30, from /tmp/yaourt-tmp-arithemetica/aur-gazebo/src/gazebo-9.0.0/gazebo/rendering/ogre_gazebo.h:67, from /tmp/yaourt-tmp-arithemetica/aur-gazebo/src/gazebo-9.0.0/gazebo/rendering/CustomPSSMShadowCameraSetup.hh:21, from /tmp/yaourt-tmp-arithemetica/aur-gazebo/src/gazebo-9.0.0/gazebo/rendering/CustomPSSMShadowCameraSetup.cc:50:

/usr/include/OGRE/RTShaderSystem/OgreShaderPrerequisites.h:67:7: note: forward declaration of 'class Ogre::RTShader::Function' class Function;

Please let me know about issues with gazebo 9.

Does anybody have an idea why the ignition-* dependencies are colored red? It usually means that they are not available, but they clearly exist.

I'm in the process of updating to gazebo 9. I first need to create a number of new ignition-* packages ...

CMake fails with error:

Missing: SDF version >=5.0.0. Required for reading and writing SDF files.

The sdformat package was recently updated to 6.0.0. Gazebo builds when I downgrade to sdformat 5.3.0.

gazebo 9.0.0 is out and it is not enough to just bump the version in the PKGBUILD. I'll look at it over the next few days. If somebody gets done before me, let me know ;)

Update regarding the tinyxml issue: There's an upstream patch I am going to backport: https://bitbucket.org/osrf/gazebo/commits/c5384ad9c4663756b5302dbc8ac1146dd57ed94e

gazebo 8.2 seems to work as described by kartikmohta. However, gazebo --verbose prints the following messages, which I am currently looking into:

libpng error: Read Error

[Wrn] [GuiIface.cc:117] QPixmap::scaled: Pixmap is a null pixmap

libpng error: Read Error

[Wrn] [GuiIface.cc:117] QPixmap::scaled: Pixmap is a null pixmap

[Err] [RenderEngine.cc:531] Unable to parse material file["/home/racko/aur/gazebo/src/gazebo-8.2.0/media/materials/scripts/ShadowCaster.material"]

[Err] [RenderEngine.cc:531] Unable to parse material file["/home/racko/aur/gazebo/src/gazebo-8.2.0/media/materials/scripts/VPL.material"]

[Err] [RenderEngine.cc:531] Unable to parse material file["/home/racko/aur/gazebo/src/gazebo-8.2.0/media/materials/scripts/blur.material"]

[Err] [RenderEngine.cc:531] Unable to parse material file["/home/racko/aur/gazebo/src/gazebo-8.2.0/media/materials/scripts/deferred_post.material"]

[Err] [RenderEngine.cc:531] Unable to parse material file["/home/racko/aur/gazebo/src/gazebo-8.2.0/media/materials/scripts/deferred_post_minilight.material"]

[Err] [RenderEngine.cc:531] Unable to parse material file["/home/racko/aur/gazebo/src/gazebo-8.2.0/media/materials/scripts/gazebo.material"]

[Err] [RenderEngine.cc:531] Unable to parse material file["/home/racko/aur/gazebo/src/gazebo-8.2.0/media/materials/scripts/grid.material"]

[Err] [RenderEngine.cc:531] Unable to parse material file["/home/racko/aur/gazebo/src/gazebo-8.2.0/media/materials/scripts/kitchen.material"]

[Err] [RenderEngine.cc:531] Unable to parse material file["/home/racko/aur/gazebo/src/gazebo-8.2.0/media/materials/scripts/oculus.material"]

[Err] [RenderEngine.cc:531] Unable to parse material file["/home/racko/aur/gazebo/src/gazebo-8.2.0/media/materials/scripts/picker.material"]

[Err] [RenderEngine.cc:531] Unable to parse material file["/home/racko/aur/gazebo/src/gazebo-8.2.0/media/materials/scripts/ssao.material"]

That being said, the tinyxml issue seems to be much more fun -.-*

tinyxml2 was updated yesterday to version tinyxml2 6.0.0-1 and now breaks the build at 56%. Took me half a day to figure out what the problem is. Best way to make gazebo build:

pacman -R -d -d tinyxml2

sudo pacman -U https://archive.archlinux.org/packages/t/tinyxml2/tinyxml2-5.0.1-1-x86_64.pkg.tar.xz

set tinyxml on hold in /etc/packman.conf

The ogre-1.10.patch is not required with the new version 8.2.0.