Package Details: gazebo 11.10.2-3

Git Clone URL: https://aur.archlinux.org/gazebo.git (read-only, click to copy)
Package Base: gazebo
Description: A multi-robot simulator for outdoor environments
Upstream URL: http://gazebosim.org/
Licenses: Apache
Submitter: None
Maintainer: billypilgrim
Last Packager: billypilgrim
Votes: 32
Popularity: 0.075969
First Submitted: 2008-10-18 22:59 (UTC)
Last Updated: 2022-05-13 08:46 (UTC)

Pinned Comments

billypilgrim commented on 2022-05-09 16:04 (UTC)

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

Latest Comments

billypilgrim commented on 2022-05-09 16:04 (UTC)

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

billypilgrim commented on 2022-05-09 15:22 (UTC)

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.

wbthomason commented on 2022-05-06 16:54 (UTC)

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

leuko commented on 2022-05-06 08:23 (UTC) (edited on 2022-05-06 08:23 (UTC) by leuko)

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

wbthomason commented on 2022-04-25 19:34 (UTC)

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.

stefano.p commented on 2022-04-25 07:34 (UTC) (edited on 2022-04-25 07:35 (UTC) by stefano.p)

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

bobosito commented on 2022-02-27 15:31 (UTC) (edited on 2022-03-04 15:41 (UTC) by bobosito)

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

bobosito commented on 2022-02-27 14:22 (UTC)

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.

joanmanel commented on 2022-02-24 16:45 (UTC) (edited on 2022-02-24 16:47 (UTC) by joanmanel)

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]

bobosito commented on 2022-02-14 04:36 (UTC)

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?

billypilgrim commented on 2022-02-13 12:06 (UTC)

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

bobosito commented on 2022-02-12 20:56 (UTC)

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

ashfaqf commented on 2022-02-12 12:56 (UTC)

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

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

bobosito commented on 2022-02-10 22:05 (UTC)

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.

Kanishk598 commented on 2022-02-02 21:28 (UTC)

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

bobosito commented on 2022-01-21 04:55 (UTC) (edited on 2022-01-21 05:04 (UTC) by bobosito)

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.

bobosito commented on 2022-01-21 03:55 (UTC) (edited on 2022-01-21 05:01 (UTC) by bobosito)

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?

Kanishk598 commented on 2022-01-17 12:32 (UTC)

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.

billypilgrim commented on 2022-01-17 11:51 (UTC)

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

Kanishk598 commented on 2022-01-17 10:32 (UTC) (edited on 2022-01-17 10:33 (UTC) by Kanishk598)

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.

billypilgrim commented on 2022-01-16 15:16 (UTC)

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

Kanishk598 commented on 2022-01-16 15:05 (UTC)

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?

billypilgrim commented on 2022-01-16 14:44 (UTC)

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

Kanishk598 commented on 2022-01-16 14:37 (UTC) (edited on 2022-01-16 14:38 (UTC) by Kanishk598)

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.

billypilgrim commented on 2022-01-16 12:26 (UTC)

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.

Kanishk598 commented on 2022-01-16 09:36 (UTC)

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?

FederAndInk commented on 2021-12-28 23:59 (UTC) (edited on 2021-12-29 00:00 (UTC) by FederAndInk)

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

billypilgrim commented on 2021-12-15 17:24 (UTC)

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

lalten commented on 2021-12-11 22:44 (UTC)

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

billypilgrim commented on 2021-09-28 10:04 (UTC)

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

fkl commented on 2021-09-28 10:02 (UTC) (edited on 2021-09-28 10:12 (UTC) by fkl)

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

billypilgrim commented on 2021-09-28 09:58 (UTC)

@fkl: Try contacting the upstream maintainers of ogre.

fkl commented on 2021-09-28 09:56 (UTC) (edited on 2021-09-28 09:57 (UTC) by fkl)

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

billypilgrim commented on 2021-09-28 09:51 (UTC)

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

fkl commented on 2021-09-28 09:48 (UTC) (edited on 2021-09-28 09:50 (UTC) by fkl)

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();

AchmadFathoni commented on 2021-09-28 03:44 (UTC)

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

billypilgrim commented on 2021-07-28 13:26 (UTC)

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

Nim65s commented on 2021-07-26 15:01 (UTC)

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

billypilgrim commented on 2021-07-01 14:51 (UTC)

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

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

t00manysecrets commented on 2021-07-01 14:23 (UTC)

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

billypilgrim commented on 2021-06-30 14:12 (UTC)

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

t00manysecrets commented on 2021-06-30 13:29 (UTC) (edited on 2021-06-30 13:33 (UTC) by t00manysecrets)

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?

AchmadFathoni commented on 2021-06-01 10:12 (UTC) (edited on 2021-06-02 17:21 (UTC) by AchmadFathoni)

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

billypilgrim commented on 2021-05-18 09:31 (UTC)

@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

AchmadFathoni commented on 2021-05-11 12:36 (UTC) (edited on 2021-05-12 04:28 (UTC) by AchmadFathoni)

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.

h_b commented on 2021-05-11 12:25 (UTC) (edited on 2021-05-11 12:27 (UTC) by h_b)

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

AchmadFathoni commented on 2021-05-02 12:40 (UTC)

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

billypilgrim commented on 2021-04-22 10:08 (UTC)

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.

Homalozoa commented on 2021-04-22 05:09 (UTC) (edited on 2021-04-22 05:09 (UTC) by Homalozoa)

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

AchmadFathoni commented on 2021-04-21 16:11 (UTC)

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

billypilgrim commented on 2021-04-21 13:21 (UTC)

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.

AchmadFathoni commented on 2021-04-21 13:09 (UTC)

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

billypilgrim commented on 2021-04-21 13:03 (UTC)

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

AchmadFathoni commented on 2021-04-21 12:57 (UTC)

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

Any idea?

billypilgrim commented on 2021-04-19 17:54 (UTC)

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

codemonkey94 commented on 2021-04-19 17:21 (UTC)

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

billypilgrim commented on 2021-04-19 11:32 (UTC)

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

julianoes commented on 2021-04-19 10:18 (UTC) (edited on 2021-04-19 10:19 (UTC) by julianoes)

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

pandaero commented on 2021-03-29 17:21 (UTC)

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.

billypilgrim commented on 2020-12-11 12:05 (UTC)

Ahh, mystery solved. Nvm then :-)

Nim65s commented on 2020-12-11 09:55 (UTC)

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 commented on 2020-12-11 00:45 (UTC)

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

billypilgrim commented on 2020-12-10 22:36 (UTC)

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

acxz commented on 2020-12-10 17:37 (UTC)

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

billypilgrim commented on 2020-12-10 11:04 (UTC)

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)

Homalozoa commented on 2020-12-10 07:38 (UTC) (edited on 2020-12-10 08:31 (UTC) by Homalozoa)

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.

leuko commented on 2020-08-04 18:20 (UTC)

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

acxz commented on 2020-05-27 18:18 (UTC) (edited on 2020-05-27 18:18 (UTC) by acxz)

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

billypilgrim commented on 2020-05-27 17:45 (UTC)

@acxz That looks cool! Nice work.

acxz commented on 2020-05-27 16:59 (UTC)

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

billypilgrim commented on 2020-05-27 16:35 (UTC)

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

acxz commented on 2020-05-27 12:18 (UTC)

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

ramdambo commented on 2020-05-27 11:18 (UTC)

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

billypilgrim commented on 2020-04-20 12:09 (UTC)

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

julianoes commented on 2020-04-20 11:56 (UTC)

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);
      |                                                                                     ^

insaanimanav commented on 2020-04-20 11:41 (UTC)

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

billypilgrim commented on 2020-04-16 19:08 (UTC)

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.

acxz commented on 2020-04-09 22:50 (UTC)

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

MaEtUgR commented on 2020-04-09 09:56 (UTC)

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

kartikmohta commented on 2020-04-09 06:01 (UTC)

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

billypilgrim commented on 2020-03-30 15:15 (UTC)

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.

bionade24 commented on 2020-03-30 13:45 (UTC)

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

MaEtUgR commented on 2020-03-30 13:30 (UTC) (edited on 2020-03-30 13:32 (UTC) by MaEtUgR)

@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

bionade24 commented on 2020-03-30 09:55 (UTC)

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

julianoes commented on 2020-03-30 09:13 (UTC)

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!

MaEtUgR commented on 2020-03-29 19:18 (UTC) (edited on 2020-03-30 14:22 (UTC) by MaEtUgR)

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

bionade24 commented on 2020-03-29 11:04 (UTC)

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

billypilgrim commented on 2020-03-18 18:27 (UTC)

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.

acxz commented on 2020-01-16 14:24 (UTC)

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

billypilgrim commented on 2020-01-16 12:11 (UTC)

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

eadan97 commented on 2020-01-16 07:12 (UTC)

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

DanielNak commented on 2020-01-16 03:12 (UTC)

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.

acxz commented on 2020-01-16 00:20 (UTC) (edited on 2020-01-16 01:17 (UTC) by acxz)

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

jhbruhn commented on 2020-01-16 00:02 (UTC)

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?

billypilgrim commented on 2020-01-15 21:48 (UTC)

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

bionade24 commented on 2020-01-15 18:48 (UTC)

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

acxz commented on 2020-01-15 02:39 (UTC)

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

billypilgrim commented on 2020-01-14 12:41 (UTC)

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

Nim65s commented on 2020-01-11 20:25 (UTC)

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 ?

stertingen commented on 2020-01-03 13:09 (UTC)

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

ubuntourist commented on 2020-01-02 11:06 (UTC)

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

billypilgrim commented on 2020-01-02 10:18 (UTC)

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

ubuntourist commented on 2020-01-02 00:40 (UTC)

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

ubuntourist commented on 2020-01-01 23:16 (UTC) (edited on 2020-01-01 23:25 (UTC) by ubuntourist)

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.

csharpron commented on 2019-12-27 03:14 (UTC) (edited on 2019-12-27 03:15 (UTC) by csharpron)

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.

Cubimon commented on 2019-12-26 16:51 (UTC)

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

greghab commented on 2019-12-24 14:44 (UTC)

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

acxz commented on 2019-12-24 14:36 (UTC)

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

acxz commented on 2019-12-24 12:52 (UTC) (edited on 2019-12-24 12:53 (UTC) by acxz)

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

greghab commented on 2019-12-24 11:46 (UTC) (edited on 2019-12-24 11:54 (UTC) by greghab)

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.

julianoes commented on 2019-12-24 10:20 (UTC)

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?

acxz commented on 2019-12-18 04:33 (UTC)

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

acxz commented on 2019-12-18 04:29 (UTC)

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

lucasmazz commented on 2019-12-17 22:09 (UTC)

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.

leuko commented on 2019-11-30 08:35 (UTC)

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

MaEtUgR commented on 2019-10-25 03:05 (UTC)

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

MaEtUgR commented on 2019-10-23 14:51 (UTC) (edited on 2019-10-23 14:51 (UTC) by MaEtUgR)

@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

MaEtUgR commented on 2019-10-17 09:43 (UTC)

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.

billypilgrim commented on 2019-10-16 15:40 (UTC)

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

bobpaul commented on 2019-10-16 01:50 (UTC) (edited on 2019-10-16 01:52 (UTC) by bobpaul)

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

billypilgrim commented on 2019-10-14 12:33 (UTC)

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.

MaEtUgR commented on 2019-10-13 15:01 (UTC) (edited on 2019-10-13 15:02 (UTC) by MaEtUgR)

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?

acxz commented on 2019-10-06 00:14 (UTC)

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

billypilgrim commented on 2019-10-05 13:42 (UTC)

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.

acxz commented on 2019-10-05 06:15 (UTC)

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

acxz commented on 2019-10-05 06:14 (UTC)

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

acxz commented on 2019-10-05 06:11 (UTC)

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

lucasmazz commented on 2019-10-05 02:24 (UTC) (edited on 2019-10-05 02:33 (UTC) by lucasmazz)

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)

billypilgrim commented on 2019-10-04 09:45 (UTC)

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.

zigas commented on 2019-10-03 20:23 (UTC) (edited on 2019-10-03 20:24 (UTC) by zigas)

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

billypilgrim commented on 2019-09-23 06:18 (UTC)

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

acxz commented on 2019-09-22 21:57 (UTC)

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

acxz commented on 2019-08-08 16:45 (UTC)

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

acxz commented on 2019-07-08 18:41 (UTC)

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.

billypilgrim commented on 2019-07-08 14:50 (UTC)

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

acxz commented on 2019-07-06 00:41 (UTC)

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

Morganamilo commented on 2019-07-05 17:13 (UTC)

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

acxz commented on 2019-07-05 16:57 (UTC)

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

Morganamilo commented on 2019-07-04 18:32 (UTC)

Please avoid using versioned depends.

commented on 2019-07-01 16:36 (UTC)

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

commented on 2019-06-30 09:01 (UTC)

@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')

acxz commented on 2019-06-29 14:36 (UTC) (edited on 2019-06-29 19:06 (UTC) by acxz)

@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

commented on 2019-06-29 10:15 (UTC)

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

Nim65s commented on 2019-01-21 09:08 (UTC)

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

GPereira commented on 2019-01-11 22:22 (UTC)

Yes, of course. Sorry busy day.

lopsided98 commented on 2019-01-11 21:56 (UTC)

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.

GPereira commented on 2019-01-11 21:01 (UTC)

Right :D fixed!

lopsided98 commented on 2019-01-11 20:39 (UTC) (edited on 2019-01-11 20:41 (UTC) by lopsided98)

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

GPereira commented on 2019-01-11 18:34 (UTC)

Fixed that

GPereira commented on 2019-01-11 08:40 (UTC)

Thanks! Will fix that later today

lopsided98 commented on 2019-01-11 02:44 (UTC)

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

ArchKermit commented on 2018-11-12 18:09 (UTC)

It works, thank you very much!

tsp commented on 2018-11-12 09:49 (UTC)

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.

ArchKermit commented on 2018-11-07 10:36 (UTC) (edited on 2018-11-07 12:50 (UTC) by ArchKermit)

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.

Eyolon commented on 2018-11-06 21:13 (UTC) (edited on 2018-11-06 21:14 (UTC) by Eyolon)

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)

GPereira commented on 2018-11-03 17:57 (UTC)

@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! :)

tsp commented on 2018-10-17 07:32 (UTC)

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.

teiesti commented on 2018-10-16 14:15 (UTC)

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

nicolino commented on 2018-10-15 14:18 (UTC) (edited on 2018-10-15 14:19 (UTC) by nicolino)

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

teiesti commented on 2018-10-15 11:42 (UTC)

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?

GPereira commented on 2018-10-08 17:36 (UTC)

It's fixed! ;)

GPereira commented on 2018-10-08 17:21 (UTC)

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.

eschwartz commented on 2018-10-08 17:08 (UTC)

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.

eschwartz commented on 2018-10-07 18:35 (UTC) (edited on 2018-10-07 18:39 (UTC) by eschwartz)

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

GPereira commented on 2018-10-04 17:44 (UTC)

thanks! Updated and fixed version

miramur commented on 2018-10-03 16:51 (UTC)

@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

portaloffreedom commented on 2018-10-01 16:28 (UTC) (edited on 2018-10-01 16:28 (UTC) by portaloffreedom)

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

miramur commented on 2018-09-16 06:46 (UTC) (edited on 2018-09-16 07:20 (UTC) by miramur)

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 (UTC)

@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 (UTC) (edited on 2018-09-10 14:38 (UTC) by nicolino)

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 (UTC) (edited on 2018-09-10 14:20 (UTC) by nicolino)

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 (UTC)

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

tsp commented on 2018-09-08 13:34 (UTC) (edited on 2018-09-08 13:34 (UTC) by tsp)

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

nicolino commented on 2018-09-08 11:51 (UTC) (edited on 2018-09-08 12:35 (UTC) by nicolino)

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 (UTC)

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 (UTC)

So is it possible to put nicolino patch in build ?

cptnapalm commented on 2018-08-28 22:49 (UTC)

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.

nicolino commented on 2018-08-14 19:06 (UTC) (edited on 2018-08-14 19:08 (UTC) by nicolino)

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

nodabba commented on 2018-08-14 17:51 (UTC)

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.

nicolino commented on 2018-08-12 17:55 (UTC)

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.

nicolino commented on 2018-08-05 13:46 (UTC) (edited on 2018-08-05 13:47 (UTC) by nicolino)

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

1CatchMe1 commented on 2018-08-01 20:51 (UTC)

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

greboide commented on 2018-07-22 17:22 (UTC)

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

1CatchMe1 commented on 2018-07-14 14:44 (UTC)

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

jlecoeur commented on 2018-07-14 10:46 (UTC)

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!

braineniac commented on 2018-07-14 10:21 (UTC)

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

LazyLucretia commented on 2018-07-13 19:33 (UTC)

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

rochus commented on 2018-07-03 06:35 (UTC) (edited on 2018-07-03 06:36 (UTC) by rochus)

@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

LazyLucretia commented on 2018-06-23 12:34 (UTC)

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

nicolino commented on 2018-06-22 14:47 (UTC) (edited on 2018-06-22 15:14 (UTC) by nicolino)

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

LazyLucretia commented on 2018-06-22 11:42 (UTC)

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

1CatchMe1 commented on 2018-06-20 06:16 (UTC)

@GPereira Could you put patches, please?

fanjiang commented on 2018-06-07 14:03 (UTC)

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

rochus commented on 2018-06-03 07:13 (UTC) (edited on 2018-06-03 14:57 (UTC) by rochus)

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

GPereira commented on 2018-06-02 18:37 (UTC)

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

Nimoab commented on 2018-05-14 03:00 (UTC) (edited on 2018-05-14 03:01 (UTC) by Nimoab)

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

Hope it helps.

al3xst commented on 2018-05-08 19:54 (UTC)

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.

racko commented on 2018-03-05 19:50 (UTC)

Interesting. Thanks for the feedback.

lennonwoo commented on 2018-03-05 04:20 (UTC)

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

racko commented on 2018-03-02 18:04 (UTC) (edited on 2018-03-02 18:05 (UTC) by racko)

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.

lennonwoo commented on 2018-03-01 06:07 (UTC) (edited on 2018-03-01 06:10 (UTC) by lennonwoo)

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

FabioLolix commented on 2018-02-27 16:29 (UTC)

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

GPereira commented on 2018-02-27 14:13 (UTC)

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

racko commented on 2018-02-24 17:08 (UTC)

Fixed.

racko commented on 2018-02-24 17:00 (UTC)

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

osjacky430 commented on 2018-02-24 16:59 (UTC) (edited on 2018-02-24 17:02 (UTC) by osjacky430)

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;

racko commented on 2018-02-24 12:20 (UTC)

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.

racko commented on 2018-02-24 10:32 (UTC)

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

darsor commented on 2018-02-24 01:44 (UTC)

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.

racko commented on 2018-02-05 20:31 (UTC)

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

racko commented on 2017-12-12 19:04 (UTC)

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

racko commented on 2017-12-12 18:48 (UTC) (edited on 2017-12-12 18:59 (UTC) by racko)

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

mr_paja commented on 2017-12-12 18:44 (UTC) (edited on 2017-12-12 18:45 (UTC) by mr_paja)

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

kartikmohta commented on 2017-12-12 01:05 (UTC)

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

racko commented on 2017-11-04 09:54 (UTC)

Also, you need to rebuild ignition-transport (before rebuilding gazebo): /usr/bin/ld: warning: libprotobuf.so.13, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libignition-transport3.so, not found Since it is only a warning it is easy to overlook during compilation ...

racko commented on 2017-11-04 09:33 (UTC)

The /usr/include/ignition/msgs0 files that the compiler complains about are neither part of gazebo nor of protobuf: $ pacman -Qo /usr/include/ignition/msgs0 /usr/include/ignition/msgs0/ is owned by ignition-msgs 0.7.0-1 That's what you need to rebuild before you rebuild gazebo ;)

patrickelectric commented on 2017-11-03 23:38 (UTC)

Problem with Gazebo and the new protobuf version ``` In file included from /tmp/yaourt-tmp-patrick/aur-gazebo/src/gazebo-8.1.1/gazebo/msgs/msgs.hh:32:0, from /tmp/yaourt-tmp-patrick/aur-gazebo/src/gazebo-8.1.1/gazebo/msgs/msgs.cc:26: /usr/include/ignition/msgs0/ignition/msgs/color.pb.h:17:2: error: #error This file was generated by an older version of protoc which is #error This file was generated by an older version of protoc which is ^~~~~ /usr/include/ignition/msgs0/ignition/msgs/color.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please #error incompatible with your Protocol Buffer headers. Please ^~~~~ /usr/include/ignition/msgs0/ignition/msgs/color.pb.h:19:2: error: #error regenerate this file with a newer version of protoc. #error regenerate this file with a newer version of protoc. ``` And isn't possible to compile protobuf3-git, it's failing.

racko commented on 2017-10-16 17:11 (UTC)

> Can you move from qtwebkit to qtwebkit-bin ? The package is unmaintained. Prefer https://aur.archlinux.org/packages/gazebo-ogre-1.10. > libboost_system.so.1.64.0, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so, not found You have to rebuild sdformat because boost was updated. That's an issue with AUR in general. You will have to rebuild sdformat for gazebo-ogre-1.10 as well.

patrickelectric commented on 2017-10-16 16:12 (UTC)

``` [ 83%] Linking CXX executable gzserver /usr/bin/ld: warning: libboost_system.so.1.64.0, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_filesystem.so.1.64.0, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_program_options.so.1.64.0, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_regex.so.1.64.0, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libboost_iostreams.so.1.64.0, needed by /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so, not found (try using -rpath or -rpath-link) /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106400::cpp_regex_traits_implementation<char>::transform_primary[abi:cxx11](char const*, char const*) const' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106400::verify_options(unsigned int, boost::regex_constants::_match_flags)' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106400::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags)' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106400::get_mem_block()' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106400::cpp_regex_traits_implementation<char>::transform[abi:cxx11](char const*, char const*) const' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106400::put_mem_block(void*)' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106400::get_default_error_string(boost::regex_constants::error_type)' /usr/lib/gcc/x86_64-pc-linux-gnu/7.2.0/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106400::raise_runtime_error(std::runtime_error const&)' collect2: error: ld returned 1 exit status make[2]: *** [gazebo/CMakeFiles/gzserver.dir/build.make:133: gazebo/gzserver-8.1.1] Error 1 make[1]: *** [CMakeFiles/Makefile2:937: gazebo/CMakeFiles/gzserver.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... ```

patrickelectric commented on 2017-10-16 02:26 (UTC)

Can you move from qtwebkit to qtwebkit-bin ?

lefamz commented on 2017-09-25 11:06 (UTC) (edited on 2017-09-25 14:47 (UTC) by lefamz)

Racko: yes, I edited PKGBUILD of qtwebkit to get this done and solve errors on-the-fly. However I was unable to build it to the end. These errors occured about 68% of make run. -- Thanks for suggestion, I will try to build https://aur.archlinux.org/packages/gazebo-ogre-1.10/ instead. Edit: successfull build. Thank you.

racko commented on 2017-09-22 17:43 (UTC)

Fixed in https://aur.archlinux.org/packages/gazebo-ogre-1.10/. I also created an upstream pull request which removes the "std::cout"s instead of adding the missing <iostream> include. I guess that makes more sense: https://bitbucket.org/osrf/gazebo/pull-requests/2778/removed-std-cout-logging-output ---- I wonder how you got that far with this package (https://aur.archlinux.org/packages/gazebo/). Me and various other people weren't able to build it (see comments below), which is why I created gazebo-ogre-1.10. Being able to build with the official community/ogre-1.10 package was just an afterthought. Or did you modify the PKGBUILD and the cout bug was the first thing you couldn't fix by yourself?

lefamz commented on 2017-09-22 14:36 (UTC)

Hi all, trying to build current package and getting several errors: /tmp/yaourt-tmp-michal/aur-gazebo/src/gazebo-8.0.0/gazebo/rendering/deferred_shading/MergeMaterialGenerator.cc: In member function ‘virtual Ogre::GpuProgramPtr MergeMaterialGeneratorImpl::GenerateVertexShader(gazebo::rendering::MaterialGenerator::Perm)’: /tmp/yaourt-tmp-michal/aur-gazebo/src/gazebo-8.0.0/gazebo/rendering/deferred_shading/MergeMaterialGenerator.cc:104:8: error: ‘cout’ is not a member of ‘std’ std::cout << programSource << "\n"; ^~~~ /tmp/yaourt-tmp-michal/aur-gazebo/src/gazebo-8.0.0/gazebo/rendering/deferred_shading/MergeMaterialGenerator.cc:104:8: note: suggested alternative: ‘count’ std::cout << programSource << "\n"; ^~~~ count /tmp/yaourt-tmp-michal/aur-gazebo/src/gazebo-8.0.0/gazebo/rendering/deferred_shading/MergeMaterialGenerator.cc: In member function ‘virtual Ogre::GpuProgramPtr MergeMaterialGeneratorImpl::GenerateFragmentShader(gazebo::rendering::MaterialGenerator::Perm)’: /tmp/yaourt-tmp-michal/aur-gazebo/src/gazebo-8.0.0/gazebo/rendering/deferred_shading/MergeMaterialGenerator.cc:297:8: error: ‘cout’ is not a member of ‘std’ std::cout << programSource << "\n"; ^~~~ /tmp/yaourt-tmp-michal/aur-gazebo/src/gazebo-8.0.0/gazebo/rendering/deferred_shading/MergeMaterialGenerator.cc:297:8: note: suggested alternative: ‘count’ std::cout << programSource << "\n"; ^~~~ count Which is weird. Any ideas how to get rid of it?

racko commented on 2017-08-13 17:46 (UTC)

You have to rebuild sdformat because boost was upgraded from 1.63.0 to 1.64.0: $ nm -CD /usr/lib/libboost_regex.so.1.64.0 | grep get_mem_block 00000000000b09b0 T boost::re_detail_106400::get_mem_block()

tve commented on 2017-08-10 15:24 (UTC)

The latest PKGBUILD errors for me, anyone have a suggestion? /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106300::cpp_regex_traits_implementation<char>::transform_primary[abi:cxx11](char const*, char const*) const' /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106300::verify_options(unsigned int, boost::regex_constants::_match_flags)' /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106300::put_mem_block(void*)' /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106300::cpp_regex_traits_implementation<char>::transform[abi:cxx11](char const*, char const*) const' /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106300::get_default_error_string(boost::regex_constants::error_type)' /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106300::get_mem_block()' /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106300::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags)' /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/libsdformat.so: undefined reference to `boost::re_detail_106300::raise_runtime_error(std::runtime_error const&)' collect2: error: ld returned 1 exit status make[2]: *** [gazebo/gui/CMakeFiles/gzclient.dir/build.make:302: gazebo/gui/gzclient-8.0.0] Error 1 make[1]: *** [CMakeFiles/Makefile2:3278: gazebo/gui/CMakeFiles/gzclient.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs....

racko commented on 2017-08-07 04:55 (UTC)

I added a new gazebo package that should fix dependency issues and use community/ogre instead of aur/ogre-1.8. I would appreciate your feedback: https://aur.archlinux.org/packages/gazebo-ogre-1.10/

yimingl commented on 2017-08-03 00:07 (UTC)

@kartikmohta, Thanks for the update. but qwt-qt5 is currently gone from AUR.

kartikmohta commented on 2017-08-01 22:54 (UTC)

Updated PKGBUILD for v8.1.1 + changed qt4 dependency to qt5: https://gist.github.com/kartikmohta/c8224bf3174016feb44b3a7b59f59047

wbthomason commented on 2017-06-30 17:19 (UTC)

The updated version of tinyxml2 in community lets this compile. However, I'm only getting segfaults when I run gazebo or gzclient. Not the same messages as you, @1CatchMe1, just immediate segfaults. gdb indicates that it's somewhere in the Qt code. Has anyone else run into/fixed this?

1CatchMe1 commented on 2017-06-28 18:11 (UTC) (edited on 2017-07-01 16:00 (UTC) by 1CatchMe1)

I am getting "escalating to SIGKILL on server" when I run gazebo then exit And when I run: $gzclient --verbos Gazebo multi-robot simulator, version 8.1.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: Segmentation fault (core dumped)

wbthomason commented on 2017-06-28 18:08 (UTC)

@1CatchMe1: Ah, thanks. I hadn't found that issue. It looks like the tinyxml2 developer has released a minor version (5.0.1) claiming to fix this issue. I've flagged the relevant package as out of date, which will hopefully help fix this package.

1CatchMe1 commented on 2017-06-28 17:49 (UTC)

you have to downgrade tinyxml2 to 4 OR see this: https://github.com/leethomason/tinyxml2/issues/498 I have just installed it now and it has been built successfully.

wbthomason commented on 2017-06-26 21:21 (UTC)

This is failing to build for me (with either the current PKGBUILD or the PKGBUILD in the gist linked by @zaidan) with a linking error: "util/libgazebo_util.so.8.0.0: undefined reference to `tinyxml2::StrPair::GetStr()' I've reinstalled tinyxml2, but with no luck. Has anyone gotten this to build recently?

zaidan commented on 2017-06-09 14:39 (UTC)

had to rebuild ignition-msgs

zaidan commented on 2017-06-09 12:41 (UTC)

@marauder yuxiang.li's PKGBUILD fixed by jap48 and published here by mimoralea as gist was the last working PKGBUILD: https://gist.github.com/mimoralea/fc78869ed9236e34b38def9920831a6b but it is broken after protobuf update: https://git.archlinux.org/svntogit/packages.git/log/trunk?h=packages/protobuf [ 25%] Building CXX object gazebo/msgs/CMakeFiles/gazebo_msgs.dir/msgs.cc.o In file included from /AUR/gazebo/src/osrf-gazebo-85ba68a2545f/gazebo/msgs/msgs.hh:32:0, from /AUR/gazebo/src/osrf-gazebo-85ba68a2545f/gazebo/msgs/msgs.cc:26: /usr/include/ignition/msgs0/ignition/msgs/color.pb.h:17:2: error: #error This file was generated by an older version of protoc which is #error This file was generated by an older version of protoc which is ^~~~~ /usr/include/ignition/msgs0/ignition/msgs/color.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please #error incompatible with your Protocol Buffer headers. Please ^~~~~ /usr/include/ignition/msgs0/ignition/msgs/color.pb.h:19:2: error: #error regenerate this file with a newer version of protoc. #error regenerate this file with a newer version of protoc. ^~~~~ In file included from /usr/include/ignition/msgs0/ignition/msgs/color.pb.h:31:0, from /AUR/gazebo/src/osrf-gazebo-85ba68a2545f/gazebo/msgs/msgs.hh:32, from /AUR/gazebo/src/osrf-gazebo-85ba68a2545f/gazebo/msgs/msgs.cc:26: /usr/include/ignition/msgs0/ignition/msgs/header.pb.h:17:2: error: #error This file was generated by an older version of protoc which is #error This file was generated by an older version of protoc which is ^~~~~ /usr/include/ignition/msgs0/ignition/msgs/header.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please #error incompatible with your Protocol Buffer headers. Please ^~~~~ /usr/include/ignition/msgs0/ignition/msgs/header.pb.h:19:2: error: #error regenerate this file with a newer version of protoc. #error regenerate this file with a newer version of protoc. ^~~~~ In file included from /usr/include/ignition/msgs0/ignition/msgs/header.pb.h:31:0, from /usr/include/ignition/msgs0/ignition/msgs/color.pb.h:31, from /AUR/gazebo/src/osrf-gazebo-85ba68a2545f/gazebo/msgs/msgs.hh:32, from /AUR/gazebo/src/osrf-gazebo-85ba68a2545f/gazebo/msgs/msgs.cc:26: /usr/include/ignition/msgs0/ignition/msgs/time.pb.h:17:2: error: #error This file was generated by an older version of protoc which is #error This file was generated by an older version of protoc which is ^~~~~ /usr/include/ignition/msgs0/ignition/msgs/time.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please #error incompatible with your Protocol Buffer headers. Please ^~~~~ /usr/include/ignition/msgs0/ignition/msgs/time.pb.h:19:2: error: #error regenerate this file with a newer version of protoc. #error regenerate this file with a newer version of protoc. ^~~~~ In file included from /AUR/gazebo/src/osrf-gazebo-85ba68a2545f/gazebo/msgs/msgs.hh:33:0, from /AUR/gazebo/src/osrf-gazebo-85ba68a2545f/gazebo/msgs/msgs.cc:26: /usr/include/ignition/msgs0/ignition/msgs/material.pb.h:17:2: error: #error This file was generated by an older version of protoc which is #error This file was generated by an older version of protoc which is ^~~~~ /usr/include/ignition/msgs0/ignition/msgs/material.pb.h:18:2: error: #error incompatible with your Protocol Buffer headers. Please #error incompatible with your Protocol Buffer headers. Please ^~~~~ /usr/include/ignition/msgs0/ignition/msgs/material.pb.h:19:2: error: #error regenerate this file with a newer version of protoc. #error regenerate this file with a newer version of protoc. ^~~~~ make[2]: *** [gazebo/msgs/CMakeFiles/gazebo_msgs.dir/build.make:4159: gazebo/msgs/CMakeFiles/gazebo_msgs.dir/msgs.cc.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:1110: gazebo/msgs/CMakeFiles/gazebo_msgs.dir/all] Error 2 make: *** [Makefile:141: all] Error 2

ryanvade commented on 2017-06-06 02:48 (UTC)

seems to no longer be building for me: /tmp/yaourt-tmp-ryan/aur-gazebo/src/gazebo-8.0.0/gazebo/common/VideoEncoder.cc: In member function ‘bool gazebo::common::VideoEncoder::Start(const string&, const string&, unsigned int, unsigned int, unsigned int, unsigned int)’: /tmp/yaourt-tmp-ryan/aur-gazebo/src/gazebo-8.0.0/gazebo/common/VideoEncoder.cc:283:5: error: ‘avformat_alloc_output_context2’ was not declared in this scope avformat_alloc_output_context2(&this->dataPtr->formatCtx, nullptr, nullptr, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /tmp/yaourt-tmp-ryan/aur-gazebo/src/gazebo-8.0.0/gazebo/common/VideoEncoder.cc:283:5: note: suggested alternative: ‘avformat_alloc_context’ avformat_alloc_output_context2(&this->dataPtr->formatCtx, nullptr, nullptr, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ avformat_alloc_context /tmp/yaourt-tmp-ryan/aur-gazebo/src/gazebo-8.0.0/gazebo/common/VideoEncoder.cc:305:14: error: ‘avcodec_get_name’ was not declared in this scope << avcodec_get_name(this->dataPtr->formatCtx->oformat->video_codec) ^~~~~~~~~~~~~~~~ /tmp/yaourt-tmp-ryan/aur-gazebo/src/gazebo-8.0.0/gazebo/common/VideoEncoder.cc:305:14: note: suggested alternative: ‘avcodec_get_type’ << avcodec_get_name(this->dataPtr->formatCtx->oformat->video_codec)

marauder commented on 2017-06-06 00:11 (UTC)

@ryanvade Updated

ryanvade commented on 2017-06-06 00:03 (UTC)

boost was updated, a minor package revision update would be nice to force a rebuild.

maarroyo commented on 2017-05-16 16:08 (UTC) (edited on 2017-05-16 19:07 (UTC) by maarroyo)

The dependency on ogre was causing issues for me. Specifically I was getting the following error message: [Err] [server_main.cc:54] Ogre Error:ItemIdentityException: Resource with the name DeferredRendering/Shadows/RSMCaster_Spot already exists. in ResourceManager::add at /build/ogre/src/ogre/OgreMain/src/OgreResourceManager.cpp (line 150) [Err] [main.cc:34] Ogre Error:ItemIdentityException: Resource with the name DeferredRendering/Shadows/RSMCaster_Spot already exists. in ResourceManager::add at /build/ogre/src/ogre/OgreMain/src/OgreResourceManager.cpp (line 150) To fix this, I ended up installing ogre-1.8 and modifying its install path to be '/usr' solved it.

japm48 commented on 2017-04-12 05:15 (UTC) (edited on 2017-04-12 05:15 (UTC) by japm48)

Please remove the qtwebkit dependency and replace it with qt5-webkit-ng. PKGBUILD from the yuxiang.li comment works perfecly after that.

yuxiang.li commented on 2017-02-25 15:11 (UTC)

It seems that Gazebo 8 is based on Qt5 instead of Qt4. The dependencies should be updated and most importantly, we need to install qwt-qt5 instead of qwt, otherwise our executable is linked to both Qt4 and Qt5 which leads to segmentation fault at start. Here is my PKGBUILD for Gazebo: https://gist.github.com/lyx-x/e6908ef82351b462d4b2e480a43b076c

marauder commented on 2017-02-19 04:17 (UTC)

Updated PKGBUILD's needed to compile gazebo 8.0.0 ignition-math 3.0.0:https://gist.github.com/anonymous/999bbd815d1eb5cadc676929b8e63383 ignition-transport 3.0.0: https://gist.github.com/anonymous/8a340176b21e8231f5875ca799a59837 sdformat 5.0.0: https://gist.github.com/anonymous/2aa6f22a05809e1c719b0805d791506c

zorun commented on 2017-02-03 17:10 (UTC)

jbuchanan30: this package is orphaned and there is a new release 8.0.0, feel free to adopt it if you want.

justbuchanan commented on 2016-11-02 05:22 (UTC) (edited on 2016-11-02 05:23 (UTC) by justbuchanan)

I updated the PKGBUILD for v7.4.0 and it builds and installs fine. You'll also need an updated version of sdformat. gazebo 7.4.0: https://gist.github.com/justbuchanan/c21ac0faed58944b740be5cfc92f4e09 sdformat 4.2.0: https://gist.github.com/justbuchanan/deb12082994047308bc1e99db959efba

mimoralea commented on 2016-10-28 22:49 (UTC)

I just had a similar issue to what @gururise described. Anaconda was the problem. I removed it from the path and then everything compiled smoothly.

gururise commented on 2016-10-21 20:50 (UTC)

Is there anyway to get this to work with protobuf3? I have a couple of packages that depend on protobuf3, but it seems protobuf and protobuf3 are in conflict.

jlecoeur commented on 2016-10-07 16:16 (UTC)

@julien2711 I had the same compilation error, your quick fix worked for me. Can it be included in the PKGBUILD?

julien2711 commented on 2016-09-29 22:06 (UTC)

sed -i 's/XML_NO_ERROR/XML_SUCCESS/' "${srcdir}/gazebo-7.1.0/gazebo/util/LogPlay.cc" in tinyxml2.h XML_NO_ERROR has been removed use the above command for quick fix

nickoe commented on 2016-03-07 18:40 (UTC) (edited on 2016-03-07 18:40 (UTC) by nickoe)

@bchretien, I can confirm that it now works with your patching. Thank your very much!

bchretien commented on 2016-03-07 08:44 (UTC)

@nickoe: it should now work with the ffmpeg package. Let me know if that works for you.

nickoe commented on 2016-03-07 07:52 (UTC)

@bchretien, ok, I will that when I get home.

bchretien commented on 2016-03-07 07:35 (UTC)

@nickoe: actually it has already been fixed upstream (https://bitbucket.org/osrf/gazebo/commits/df5f96a6695f8dbe8d05bb885aed2913a09170b9).

bchretien commented on 2016-03-07 07:24 (UTC)

@nickoe: ok the breaking change happened here: https://github.com/FFmpeg/FFmpeg/commit/78071a1420b425dfb787ac739048f523007b8139 It was actually renamed to AV_PIX_FMT_RGB24 (the ffmpeg version can be found in /usr/include/libavutil/pixfmt.h). I'll report that to the Gazebo developers.

bchretien commented on 2016-03-07 07:11 (UTC)

@nickoe: PIX_FMT_RGB24 was defined in ffmpeg (libavutil), but apparently it was removed. Can you retry with ffmpeg-2.8 installed? It should not conflict with ffmpeg AFAIK.

nickoe commented on 2016-03-07 06:58 (UTC) (edited on 2016-03-07 06:59 (UTC) by nickoe)

Hi Benjamin, I always get the following build error when I try to build gazebo. Do you have any idea of why this is happening? gazebo/common/CMakeFiles/gazebo_common.dir/build.make:902: recipe for target 'gazebo/common/CMakeFiles/gazebo_common.dir/Video.cc.o' failed make[2]: *** [gazebo/common/CMakeFiles/gazebo_common.dir/Video.cc.o] Error 1 CMakeFiles/Makefile2:968: recipe for target 'gazebo/common/CMakeFiles/gazebo_common.dir/all' failed ... Which is caused by: /magicpath/gazebo/src/gazebo-7.0.0/gazebo/common/Video.cc:150:30: error: »PIX_FMT_RGB24« was not declared in this scope avpicture_alloc(this->pic, PIX_FMT_RGB24, this->codecCtx->width, I have not yet tried to investigate the issue in detail. Could it be a dependency that I need updated first?

nicoo commented on 2016-02-28 18:45 (UTC)

@bchrectien you're very welcome, it compiles now.

bchretien commented on 2016-02-28 11:34 (UTC)

@nicoo: missing dependency on qtwebkit added, thanks!

nicoo commented on 2016-02-27 23:49 (UTC)

-> Extracting gazebo-7.0.0.tar.bz2 with bsdtar ==> Starting prepare()... (...) ====== Finding 3rd Party Packages ====== -- Operating system is Linux -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29") -- Checking for module 'freeimage>=3.9.0' -- Package 'freeimage>=3.9.0' not found -- freeimage.pc not found, trying freeimage_include_dir and freeimage_library_dir flags. -- Found /usr/include/FreeImage.h -- Looking for FreeImage.h - found -- Looking for libfreeimage - found -- Looking for pthread.h -- Looking for pthread.h - found -- Looking for pthread_create -- Looking for pthread_create - not found -- Looking for pthread_create in pthreads -- Looking for pthread_create in pthreads - not found -- Looking for pthread_create in pthread -- Looking for pthread_create in pthread - found -- Found Threads: TRUE -- Found PROTOBUF: /usr/lib64/libprotobuf.so -- Found OpenGL: /usr/lib64/libGL.so -- Found OpenAL: /usr/lib64/libopenal.so -- Could NOT find HDF5 (missing: HDF5_LIBRARIES HDF5_INCLUDE_DIRS) -- Could NOT find HDF5 (missing: HDF5_LIBRARIES HDF5_INCLUDE_DIRS) -- HDF5 not found -- Checking for module 'libcurl' -- Found libcurl, version 7.47.1 -- Checking for module 'libprofiler' -- Package 'libprofiler' not found -- Looking for libprofiler - not found -- Checking for module 'libtcmalloc' -- Package 'libtcmalloc' not found -- Looking for libtcmalloc - not found CMake Warning at cmake/SearchForStuff.cmake:139 (find_package): By not providing "FindSimbody.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Simbody", but CMake did not find one. Could not find a package configuration file provided by "Simbody" with any of the following names: SimbodyConfig.cmake simbody-config.cmake Add the installation prefix of "Simbody" to CMAKE_PREFIX_PATH or set "Simbody_DIR" to a directory containing one of the above files. If "Simbody" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): CMakeLists.txt:128 (include) -- Simbody not found, for simbody physics engine option, please install libsimbody-dev. -- Looking for DARTCore - not found -- DART not found, for dart physics engine option, please install libdart-core4-dev. -- Using system tinyxml. -- Checking for module 'tinyxml' -- Found tinyxml, version 2.6.2 -- Using system tinyxml2. -- Checking for module 'tinyxml2' -- Found tinyxml2, version 3.0.0 -- Looking for libtar.h - found -- Looking for libtar.so - found -- Checking for module 'tbb' -- Package 'tbb' not found -- TBB not found, attempting to detect manually -- Checking for module 'OGRE-RTShaderSystem>=1.7.4' -- Found OGRE-RTShaderSystem, version 1.9.0 -- Checking for module 'OGRE>=1.7.4' -- Found OGRE, version 1.9.0 -- Checking for module 'OGRE-Terrain' -- Found OGRE-Terrain, version 1.9.0 -- Checking for module 'OGRE-Overlay' -- Found OGRE-Overlay, version 1.9.0 -- Checking for module 'ccd>=1.4' -- Found ccd, version 2.0 -- Checking for module 'libswscale' -- Found libswscale, version 3.1.101 -- Checking for module 'libavformat' -- Found libavformat, version 56.40.101 -- Checking for module 'libavcodec' -- Found libavcodec, version 56.60.100 -- Checking for module 'libavutil' -- Found libavutil, version 54.31.100 -- Checking for modules 'playercore>=3.0;playerc++;playerwkb' -- Package 'playercore>=3.0' not found -- Package 'playerc++' not found -- Package 'playerwkb' not found -- Player not found, gazebo plugin for player will not be built. -- Checking for module 'gts' -- Found gts, version 0.7.6 -- Looking for GTS - found -- Checking for module 'bullet>=2.82' -- Package 'bullet>=2.82' not found -- Checking for module 'bullet2.82>=2.82' -- Package 'bullet2.82>=2.82' not found -- Bullet > 2.82 not found, for bullet physics engine option, please install libbullet2.82-dev. -- Checking for module 'libusb-1.0' -- Found libusb-1.0, version 1.0.20 -- Looking for libusb-1.0 - found. USB peripherals support enabled. -- Checking for module 'OculusVR' -- Package 'OculusVR' not found -- Oculus Rift support will be disabled. -- Boost version: 1.60.0 -- Looking for SDFormat - found -- Looking for Q_WS_X11 -- Looking for Q_WS_X11 - found -- Looking for Q_WS_WIN -- Looking for Q_WS_WIN - not found -- Looking for Q_WS_QWS -- Looking for Q_WS_QWS - not found -- Looking for Q_WS_MAC -- Looking for Q_WS_MAC - not found CMake Error at /usr/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:148 (message): Could NOT find Qt4 (missing: QT_QTWEBKIT_INCLUDE_DIR QT_QTWEBKIT_LIBRARY) (found version "4.8.7") Call Stack (most recent call first): /usr/share/cmake-3.4/Modules/FindPackageHandleStandardArgs.cmake:388 (_FPHSA_FAILURE_MESSAGE) /usr/share/cmake-3.4/Modules/FindQt4.cmake:1333 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) cmake/SearchForStuff.cmake:547 (find_package) CMakeLists.txt:128 (include) -- Configuring incomplete, errors occurred! See also "/tmp/yaourt-tmp-user/aur-gazebo/src/gazebo-7.0.0/build/CMakeFiles/CMakeOutput.log". See also "/tmp/yaourt-tmp-user/aur-gazebo/src/gazebo-7.0.0/build/CMakeFiles/CMakeError.log". ==> ERROR: A failure occurred in prepare(). Aborting... CMakeOutput.log : http://pastebin.com/LwFf7FyT CMakeError.log : http://pastebin.com/CfGXsfmC

bchretien commented on 2016-02-06 04:37 (UTC)

@sytabaresa: good catch, thanks!

sytabaresa commented on 2016-02-05 19:34 (UTC)

Gazebo needs sdformat >= 4.0.0 as dependency: -- BUILD ERRORS: These must be resolved before compiling. -- Missing: SDF version >=4.0.0. Required for reading and writing SDF files. -- END BUILD ERRORS

bchretien commented on 2016-01-31 06:02 (UTC)

@kartikmohta: thanks! I missed that in the changelog since tinyxml is already a dependency. It's fixed.

kartikmohta commented on 2016-01-30 20:03 (UTC)

Missing tinyxml2 dependency. Note that this is different from tinyxml-2.6.2.

igoralmeida commented on 2015-12-22 23:45 (UTC) (edited on 2015-12-22 23:49 (UTC) by igoralmeida)

I already have it installed, but indeed it does: 'yaourt -S --asdeps ignition-math' will try to install ruby-ronn (which I had manually uninstalled after gazebo failed to build). (Re)installation is successful. So gazebo depends on ignition-math, which in turn 'makedepends' on ruby-ronn, yet gazebo will fail to build if ruby-ronn is present. Is that a problem on my arch box only then?

bchretien commented on 2015-12-21 18:48 (UTC) (edited on 2015-12-21 18:48 (UTC) by bchretien)

@igoralmeida: AFAIK, only gazebo and ignition-math have a make dependency on ruby-ronn (or maybe in a dependency I'm not maintaining). Does this problem also happen with ignition-math? As for CMake, re-running cmake is not always enough to properly update the cache, removing it may be necessary (CMakeCache.txt). I guess after removing ruby-ronn, your CMake cache still contained the path to ronn.

igoralmeida commented on 2015-12-21 18:33 (UTC)

Something depends on ruby-ronn, such that 'yaourt -S --noconfirm ros-indigo-desktop-full' will eventually install ruby-ronn and trigger the problem below.

igoralmeida commented on 2015-11-30 17:23 (UTC)

FWIW, I managed to reproduce the issue with 'makepkg -R' inside /tmp/yaourt-tmp-ima/aur-gazebo. I then uninstalled ruby-ronn and manually ran 'cmake ...' again as specified in PKGBUILD, so it can pick up the change. Unfortunately it failed again: -- Install configuration: "Release" [ 0%] Generating gzprop.1 /bin/sh: /usr/bin/ronn: No such file or directory Finally, I gave up fighting and just installed from scratch. It works now. Thanks! PS: ros-jade being behind upstream is not really a problem, but urdf_tutorial failing when trying display.launch (error) and gazebo.launch (can't see anything except the ground plane and the red/blue/green axis) *is*, so I'll try with indigo.

bchretien commented on 2015-11-30 13:06 (UTC)

@igoralmeida: this seems to be a Ruby/ronn issue (https://github.com/rtomayko/ronn/issues/87), and ronn appears to be inactive. The easiest way to avoid the issue would be to uninstall ronn. The fact that makepkg fails, but running make from a shell works for you is surprising. I doubt this could be due to flags in /etc/makepkg.conf, and makepkg inherits your shell's settings. As for jade, know that the packages are not up to date. I'm the maintainer, but since I'm still using indigo and I'm quite busy at the moment, the packages are a few versions behind upstream.

igoralmeida commented on 2015-11-30 12:33 (UTC)

Fortunately I had the terminal open. I missed this when I first looked: ... [ 64%] Built target gazebo_gui_viewers [ 73%] Built target gazebo_gui [ 73%] Generating gzclient.1 [93/1843] /usr/lib/ruby/gems/2.2.0/gems/ronn-0.7.3/lib/ronn/document.rb:191:in `sniff': uninitialized constant Ronn::Document::Markdown (Na meError) from /usr/lib/ruby/gems/2.2.0/gems/ronn-0.7.3/lib/ronn/document.rb:76:in `initialize' from /usr/lib/ruby/gems/2.2.0/gems/ronn-0.7.3/bin/ronn:166:in `new' from /usr/lib/ruby/gems/2.2.0/gems/ronn-0.7.3/bin/ronn:166:in `block in <top (required)>' from /usr/lib/ruby/gems/2.2.0/gems/ronn-0.7.3/bin/ronn:166:in `map' from /usr/lib/ruby/gems/2.2.0/gems/ronn-0.7.3/bin/ronn:166:in `<top (required)>' from /usr/bin/ronn:23:in `load' from /usr/bin/ronn:23:in `<main>' gazebo/gui/CMakeFiles/man-gzclient.dir/build.make:64: recipe for target 'gazebo/gui/gzclient.1' failed make[4]: *** [gazebo/gui/gzclient.1] Error 1 make[4]: *** Deleting file 'gazebo/gui/gzclient.1' CMakeFiles/Makefile2:1401: recipe for target 'gazebo/gui/CMakeFiles/man-gzclient.dir/all' failed make[3]: *** [gazebo/gui/CMakeFiles/man-gzclient.dir/all] Error 2 CMakeFiles/Makefile2:78: recipe for target 'CMakeFiles/man.dir/rule' failed make[2]: *** [CMakeFiles/man.dir/rule] Error 2 Makefile:195: recipe for target 'man' failed make[1]: *** [man] Error 2 -- Installing: /tmp/yaourt-tmp-ima/aur-gazebo/pkg/gazebo/usr/include/gazebo-6.1/gazebo/gazebo_config.h -- Installing: /tmp/yaourt-tmp-ima/aur-gazebo/pkg/gazebo/usr/share/gazebo-6.1/setup.sh -- Installing: /tmp/yaourt-tmp-ima/aur-gazebo/pkg/gazebo/usr/share/gazebo/setup.sh ... And yes, I had ruby-ronn-0.7.3-3, but I reinstalled it to be sure. The problem, though, is that entering /tmp/yaourt-tmp-ima/aur-gazebo/src/gazebo-6.1.0/build/gazebo and typing "make" doesn't reproduce the problem. Is there a way to try this again without having to recompile gazebo entirely? It also might help to know that I'm upgrading from ros-hydro-* and gazebo-5.0.1-3 to ros-jade-* and gazebo-6.1.0-3.

bchretien commented on 2015-11-30 10:07 (UTC)

@igoralmeida: I haven't been able to reproduce this error. It seems that the man pages are missing when it tries to install them. Do you have ruby-ronn installed (currently listed as an optional dependency)? They check for the availability of ronn in CMake, and manpage generation is disabled if it can't be found. Are you also sure that there hasn't been any error/warning related to this before the install step?

igoralmeida commented on 2015-11-27 20:42 (UTC)

I'm getting a problem at the end of the installation: -- Installing: /tmp/yaourt-tmp-ima/aur-gazebo/pkg/gazebo/usr/lib/libgazebo_opende_ou.so.6.1.0 -- Installing: /tmp/yaourt-tmp-ima/aur-gazebo/pkg/gazebo/usr/lib/libgazebo_opende_ou.so.6 -- Installing: /tmp/yaourt-tmp-ima/aur-gazebo/pkg/gazebo/usr/lib/libgazebo_opende_ou.so -- Installing: /tmp/yaourt-tmp-ima/aur-gazebo/pkg/gazebo/usr/bin/gzserver-6.1.0 -- Installing: /tmp/yaourt-tmp-ima/aur-gazebo/pkg/gazebo/usr/bin/gzserver -- Removed runtime path from "/tmp/yaourt-tmp-ima/aur-gazebo/pkg/gazebo/usr/bin/gzserver-6.1.0" CMake Error at gazebo/cmake_install.cmake:67 (file): file INSTALL cannot find "/tmp/yaourt-tmp-ima/aur-gazebo/src/gazebo-6.1.0/build/gazebo/gzserver.1.gz". Call Stack (most recent call first): cmake_install.cmake:90 (include) Makefile:94: recipe for target 'install' failed make: *** [install] Error 1 ==> ERROR: A failure occurred in package(). Aborting... ==> ERROR: Makepkg was unable to build gazebo. How can I better debug this?

bchretien commented on 2015-05-12 05:26 (UTC)

* Patched for Boost 1.58 bug (https://bitbucket.org/osrf/gazebo/pull-request/1677/remove-from-timepanel-onfullscreen/diff) * Patched for Bullet 2.83 API change (https://bitbucket.org/osrf/gazebo/pull-request/1664/support-bullet-283/diff)

bchretien commented on 2015-04-30 02:42 (UTC)

Note: compilation currently fails with the new Boost release (1.58). For more information: https://bitbucket.org/osrf/gazebo/issue/1590/build-fails-with-boost-158

bchretien commented on 2015-02-05 10:53 (UTC)

@kartikmohta: it still used to bug with Ogre 1.9 the last time I tested, but I'll check if everything appears to be fine with the 5.0.1 release. @LikeSmith: thanks for reporting this. For /usr/lib64, this is due to a change in the latest pacman which screws things up with CMake-based PKGBUILDs on 64-bit systems (fixable by setting CMAKE_INSTALL_LIBDIR to "lib"). For the md5sum, this is weird (AFAIK they don't provide any hash so this is based on the local version I downloaded a while back). Since Gazebo 5 has been released, this will be updated anyway. As for ruby, the dependency may be ruby-ronn for the doc. I'll update the PKGBUILD soon.

LikeSmith commented on 2015-02-05 04:52 (UTC)

A couple things from my experience installing. Currently, the md5sum for the package is incorrect, also, I had to install ruby before gazebo would install (I think it required for sdformat). I've also been getting issues because "/usr/lib64 exists in filesystem" If i move lib64 to lib64.back, the install works, but it creates a new lib64 directory. The original lib64 is a symlink to the regular lib directory. Is there a solution to this problem that doesn't involve getting rid of the lib64 symlink?

kartikmohta commented on 2015-01-08 02:53 (UTC)

I think you can change the ogre-1.8 dependency to just ogre, Gazebo compiles fine with ogre 1.9 which is in the official repos. Or is that done due to some requirement of the optional dependencies?

bchretien commented on 2015-01-02 19:25 (UTC)

@sfranchi: hmmm actually the install script is still bundled so the explanation is normally done at the end of the install: > Now you need to export some Gazebo variables: > If you're using bash:" > echo 'source /usr/share/gazebo/setup.sh' >> ~/.bashrc" > source ~/.bashrc"

bchretien commented on 2015-01-02 19:14 (UTC)

@sfranchi: I guess I can add a message for those who are not aware of this.

sfranchi commented on 2015-01-02 16:05 (UTC)

@bchretien: Thanks that fixed it. I must have missed that I was supposed to run that sh file.

bchretien commented on 2014-12-30 00:55 (UTC)

@sfranchi: did you source /usr/share/gazebo/setup.sh? Can you check that it contains the proper LD_LIBRARY_PATH export?

sfranchi commented on 2014-12-29 22:14 (UTC)

I get an error when trying to launch the latest gazebo from a fresh install: [code] gazebo: error while loading shared libraries: libOgreRTShaderSystem.so.1.8.1: cannot open shared object file: No such file or directory [/code] ogre was installed as a prereq, and the library file is located in /opt/OGRE-1.8/lib Any idea on how to fix this?

bchretien commented on 2014-08-11 21:38 (UTC)

@mattre: thanks for the warning, update done ;-)

mattre commented on 2014-08-11 19:44 (UTC)

version 4.0.0 got just released

nickoe commented on 2014-06-21 21:39 (UTC)

I just built gazebo today without libccd.

costashatz commented on 2014-06-21 21:16 (UTC)

@bchretien: With libccd gazebo compiled fine. Thanks!

bchretien commented on 2014-06-21 19:52 (UTC)

@costashatz: libccd is an optional external dependency (normally gazebo switches to their internal version if libccd is not found). This could be a bug in their CMake files. I'll add libccd as a dependency, that should solve it for you.

costashatz commented on 2014-06-21 19:26 (UTC)

I am getting the following error (update to 3.0): ``/usr/bin/ld: cannot find -lccd`` Any ideas?

bchretien commented on 2014-06-19 10:23 (UTC)

@progtologist: apparently there's only a limited set of packages that have not been fixed, at least for Gazebo 2 (cf. https://github.com/turtlebot/turtlebot_create_desktop/issues/7).

bchretien commented on 2014-06-19 09:48 (UTC)

@progtologist: I just tried compiling gazebo_plugins/gazebo_ros with gazebo 3.0 for hydro and compilation worked. They just deprecated some methods which could be removed in the next release though. Do you know which parts/ROS stacks are not ABI/API compatible with gazebo 3?

bchretien commented on 2014-06-19 09:34 (UTC)

@progtologist: I know, hence the gazebo-1.9 I also uploaded. I finished fixing this one (gdal errors) at 3 AM so ROS dependencies will come next ;-) As for the API/ABI, their doc (http://gazebosim.org/wiki/Install/Gazebo_and_ROS#Using_an_specific_Gazebo_version_and_ROS) states that "there is a way of using any specific version of gazebo and ROS if really needed", which to be honest seems surprising (which is also why I froze "gazebo" to 1.9 until I found more information). I'll try to see if there's a clash with hydro or indigo. A "gazebo-2" will also probably be needed for Indigo users.

progtologist commented on 2014-06-19 07:47 (UTC)

This package as well as gazebo-1.9 should provide and conflict 'gazebo' so as to avoid trying to install both versions on the same system. Also, ros-hydro-gazebo-ros (and -groovy- probably) now tries to install this version which is wrong since hydro depends (and is API/ABI compatible) on gazebo-1.9

bchretien commented on 2013-12-21 15:33 (UTC)

@mmm: I removed the conflict between 'ogre' and 'ogre-1.8'. This should solve your problem for now.

bchretien commented on 2013-12-19 16:20 (UTC)

@mmm: Hi, I tried to update both gazebo and ogre (newer ogre + older gazebo, older ogre + newer gazebo, newer ogre + newer gazebo), and I got different errors, hence the current freeze on ogre version. If you can provide an updated PKGBUILD I would be very happy to update the package, but for now it's stuck. I will try again soon, when I find enough free time. Also, I may end up doing 2 packages, one with ROS support (1.9.2), and another one (2.1.0) (cf. http://gazebosim.org/news/2.1.0-and-1.9.2-released.html), but ogre will probably be an issue still. I could also change the paths for ogre-1.8, remove the conflicts with ogre 1.9, and force the linker to use ogre-1.8 in the Gazebo PKGBUILD.

mmm commented on 2013-12-19 16:07 (UTC)

Hi, please any chance to make this depend on ogre (current ver 1.9) and not ogre-1.8? I need the recent ogre for some other packages on my system, and those two are in conflict. (I tried to build with 1.9 version, and it's not just simple like that...) Thanks! and Merry Christmas! :)

a_user commented on 2013-06-07 18:19 (UTC)

qt moved to qt4 is it possible to provide a recent version of gazebo? 1.7.1 is the last releas

commented on 2012-05-18 14:00 (UTC)

Updated to 1.0.1. This release contains numerous bug fixes.

commented on 2012-05-13 15:36 (UTC)

I've already tried all combinations I could think of, including this one you suggested, but to no avail. I'm starting to think this might be a bug either in gazebo or even boost itself

commented on 2012-05-10 03:42 (UTC)

This error occurs due to incorrect hostname in the settings. Try this: export GAZEBO_MASTER_URI=http://127.0.0.1:12345 gzserver

commented on 2012-05-10 01:52 (UTC)

I am getting a weird error when trying to run gzserver using default settings: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::system::system_error> >' what(): resolve: Host not found (authoritative) Does anybody have any input on what causes this behavior and how to possibly solve/go around it? Thanks again, Bruno

commented on 2012-05-09 05:50 (UTC)

@brunocodutra I added these changes to 'cmake.patch'. Thanks for report!

commented on 2012-05-09 02:09 (UTC)

Hello, First of all, thanks a ton for mantaining this package! I had a couple of minor issues building gazebo. Appearently the binaries inside tools/ fail to link against pthread, but adding it manually to the respective link.txt files solves the problem. Sadly I don't quite understand cmake, otherwise I could perhaps suggest a solution, but nevertheless, I believe it to be an easy to solve issue. Best regards, Bruno