Development is on Github: https://github.com/acxz/gazebo-arch Please open issues and PRs there instead of commenting.
Search Criteria
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) |
Dependencies (33)
- boost (boost-git)
- curl (curl-minimal-git, curl-git)
- freeglut (freeglut-x11-svn, freeglut-wayland-svn)
- freeimage
- graphviz
- ignition-cmake
- ignition-common-3
- ignition-fuel_tools-4
- ignition-math
- ignition-msgs-5
- ignition-transport-8
- libccd (libccd-git, libccd)
- libltdl (libtool-git, libtool)
- libtar
- libxml2 (libxml2-git)
- ogre-1.9
- protobuf (protobuf-git)
- qwt (qwt61-multiaxes-svn)
- sdformat-9
- tbb (intel-oneapi-tbb)
- Show 13 more dependencies...
Required by (12)
- ardupilot-gazebo-sitl-git
- gazebo-model-quadrotor
- gazebo-sitl-git
- ros-arch-deps
- ros-melodic-gazebo-dev
- ros-melodic-hector-gazebo-plugins
- ros-melodic-rotors-gazebo-plugins (make)
- ros-melodic-turtlebot3-gazebo
- ros-noetic-gazebo-dev
- ros-noetic-hector-gazebo-plugins
- ros-noetic-rotors-gazebo-plugins (make)
- ros-noetic-turtlebot3-gazebo
Sources (2)
Latest Comments
billypilgrim commented on 2022-05-09 16:04 (UTC)
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)
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:
- gazebo: https://pastebin.com/5b2zzYAz
- ignition-common: https://pastebin.com/Gsqi6J6R
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.
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.