MacOs Mojave 10.14.6 Compilation

[CarlottaSartore]

Trying to compile gym-ignition on macOS Mojave 10.14.6

Installed gazebo-ignition via homebrew by following https://ignitionrobotics.org/docs/latest/install.

brew install ignition-blueprint

Needed to unlink sdformta6

brew unlink sdformat6

for using sdformat8

Installed gcc-8

brew install gcc@8

and exported

export CC=gcc-8
export CXX=g++-8

Cloned the repository, inside the repository, configure and make

mkdir build && cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/usr/local
cmake --build .

CMakeWarning

  Could not find a configuration file for package "DART" that is compatible
  with requested version "6.10.0".

  The following configuration files were considered but not accepted:

    /usr/local/share/dart/cmake/DARTConfig.cmake, version: 6.9.2

Compilation Error

[ 17%] Linking CXX shared library ../lib/libgympp.dylib
Undefined symbols for architecture x86_64:
  "ignition::common::Logger::operator()(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int)", referenced from:
      gympp::spaces::Discrete::contains(gympp::data::Sample const&) const in Space.cpp.o
      gympp::spaces::Box::contains(gympp::data::Sample const&) const in Space.cpp.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

By putting to false (not solving the problem since ignition-common3 is present in the system)

if(ignition-common3_FOUND))
    target_compile_definitions(gympp PUBLIC USE_IGNITION_LOGS)
    target_link_libraries(gympp PUBLIC
        ignition-common3::ignition-common3)
endif()

The compilation continued

[ 20%] Building CXX object ignition/CMakeFiles/RobotSingleton.dir/src/RobotSingleton.cpp.o
/Users/csartore/gym-ignition/ignition/src/RobotSingleton.cpp: In member function 'std::weak_ptr<gympp::Robot> gympp::gazebo::RobotSingleton::getRobot(const string&) const':
/Users/csartore/gym-ignition/ignition/src/RobotSingleton.cpp:56:5: error: 'assert' was not declared in this scope
     assert(pImpl->robots.at(robotName));
     ^~~~~~
/Users/csartore/gym-ignition/ignition/src/RobotSingleton.cpp:56:5: note: 'assert' is defined in header '<cassert>'; did you forget to '#include <cassert>'?
/Users/csartore/gym-ignition/ignition/src/RobotSingleton.cpp:11:1:
+#include <cassert>

/Users/csartore/gym-ignition/ignition/src/RobotSingleton.cpp:56:5:
     assert(pImpl->robots.at(robotName));
     ^~~~~~

By adding the include asked

Undefined symbols for architecture x86_64:
  "google::protobuf::MessageLite::ParseFromIstream(std::basic_istream<char, std::char_traits<char> >*)", referenced from:
      ignition::gazebo::v2::serializers::VectorDoubleSerializer::Deserialize(std::basic_istream<char, std::char_traits<char> >&, std::vector<double, std::allocator<double> >&) in IgnitionRobot.cpp.o
  "ignition::math::v6::PID::Update(double, std::chrono::duration<double, std::ratio<1l, 1l> > const&)", referenced from:
      gympp::gazebo::IgnitionRobot::update(std::chrono::duration<double, std::ratio<1l, 1l> >) in IgnitionRobot.cpp.o
  "ignition::common::env(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)", referenced from:

I have cheked and google::protobuf::MessageLite::ParseFromIstream exists in the related header located in /usr/local/Cellar/protobuf/3.10.0/include/google/protobuf/message_lite.h

[traversaro]

By quickly inspecting the ignition-gazebo homebrew formulas, it seems that they are compiled using the normal system compiler, so probably I would avoid setting manually gcc8 when compiling gym-ignition .

[diegoferigo]

@CarlottaSartore What is in Mojave the default compiler? The compilers tested by our CI infrastructure are the following:

• gcc 8
• clang 7
• clang 8

Maybe as @traversaro wrote the default version of the compiler on your OSX distribution is already good enough.

[CarlottaSartore]

The default compiler is AppleClang 11.0.0.11000033 and with that, I succeeded in compiling gym ignition.
I still have to run the example and check that everything is working fine but at least the compilation worked quite easy without setting manually gcc8.

[diegoferigo]

Cool, let us know if the examples work fine. With some work me maybe could even think to officially support osx. Though, before announcing it we should at least also 1) distribute a binary wheel for osx, and that might take some effort, and 2) have a osx maintainer (@CarlottaSartore 👀 ).

[traversaro]

Though, before announcing it we should at least also 1) distribute a binary wheel for osx, and that might take some effort, and 2) have a osx maintainer (@CarlottaSartore 👀 ).

Before deciding to distribute a binary wheel for macOS, I would first do to a due diligence on the public dependencies of ignition-gazebo, to see if they include boost or other problematic dependencies, as homebrew is unfortunately a rolling release system, so the ABI of the dependencies can change without any advice, breaking any binary that depends on such ABI. The ABI changes should not be a problem for ignition libraries as each major version is considered as a different homebrew package, but for transitive dependencies this could be a problem. See ros-infrastructure/bloom#254 (comment) for a related comment.

[IeiuniumLux]

@CarlottaSartore, out of curiosity, were you at least able to launch Ignition-Gazebo on the MacOs Mojave from command line? e.g:

$ ign gazebo -r rolling_shapes.sdf

According to this PR, the ign gazebo command line tool is not working on Mac.

@diegoferigo @traversaro, does the cartpole example make usage of the Ignition GUI Simulator? i.e. is there any rendering happening or just console outputs?

[diegoferigo]

@diegoferigo @traversaro, does the cartpole example make usage of Ignition GUI Simulator?

Gym-Ignition executes simulations typically in headless mode. The framework, in line with the OpenAI Gym interface, provides an optional render() method that spawns a new process and allows visualizing the simulated environment in a graphical frontend. In the cartpole demo the GUI is enabled by default, though commenting out the render method the execution would happen entirely in the console.

This issue describes the very first attempt on MacOs done by @CarlottaSartore, and up to today there are no further updates beyond what reported here.

What's unfortunate is that we rely to the ign gazebo -g command line to spawn the GUI process. Therefore, if the command line is not working properly on MacOs and Windows, the environments will not have rendering capabilities on those OSs.

[IeiuniumLux]

@diegoferigo thanks for the clarification. Hopefully, the coming release of Ignition-Gazebo (Citadel) in December, addresses the support for MacOS and Windows since it works great on Ubuntu 18. Thank you for contributing this great component and making this RL capability available to Ignition.

[traversaro]

What's unfortunate is that we rely to the ign gazebo -g command line to spawn the GUI process. Therefore, if the command line is not working properly on MacOs and Windows, the environments will not have rendering capabilities on those OSs.

A possible workaround (at least for Blueprint) is to use ign-gazebo -g on macOS, even if deprecated, as it is the only one currently working.

[diegoferigo]

Just to put another option on the table, there's also ign gui, even though I suspect that it is an alias of ign gazebo -g (or better, the other way around).

[diegoferigo]

@IeiuniumLux I would just try to ping in the upstream's issue. As a temporary workaround, as commented there, installing ruby from homebrew and changing the shebang should work.

[traversaro]

By the way, I actually meant to use ign-gazebo -g (with the dash between ign and gazebo) that as far as I understand should be available also on macOS in ignition-gazebo2 .

[diegoferigo]

As a test, I installed another ruby implementation with brew install ruby and modified the shebang line of /usr/local/bin/ign to point to that other ruby in /usr/local, and it was successful!

I was referring to this comment.

[traversaro]

I am afraid that @diegoferigo did not actually tried the workaround mention in that comment, so probably it would make more sense to ask to @scpeters directly.

[scpeters]

[email protected] is a forked version with some extra friction parameters that we have been using and hosting on our homebrew tap. It is keg-only so as to not interfere with the official package, but you need to set some extra environment variables to use it:

• https://bitbucket.org/osrf/release-tools/src/c6d88a6f19e5779f56ad6ec2b54fa7e3ba473d62/jenkins-scripts/lib/project-default-devel-homebrew-amd64.bash#lines-123:128

[scpeters]

that looks like the following bug, and I just replied to your comment there

• https://bitbucket.org/ignitionrobotics/ign-gazebo/issues/25/apple-support-for-ign-command-line-tool

[diegoferigo]

@CarlottaSartore Steve's comment about dart 6.10 applies also to your setup.

[diegoferigo]

Thank you @scpeters for chiming in! Let's move the discussion about the command line to the upstream issue.

[diegoferigo]

I believe that macOS situation has improved after 1.5 y. Especially, after gazebosim/gz-sim#477, the ign command line should be functional. Please reopen the issue in case of further problems.