Migrate to newer Boost library bind include directory

[mcsauder]

Hello,

This PR updates the boost library #include <boost/bind.hpp> to the new directory of the current library, <boost/bind/bind.hpp>. Updating these #include directory locations aids the migration to Ubuntu 20.04's native boost packages and Gazebo 11

This PR has been tested on Ubuntu 18.04 with Gazebo 9.

Let me know if you have any questions on this PR!

-Mark

[Jaeyoung-Lim]

@mcsauder Could you give more context regarding this change?

Also would it be possible to address the macOS failures?

[mcsauder]

@mcsauder Could you give more context regarding this change?

Hi @Jaeyoung-Lim , certainly. I have only been using jmavsim since upgrading to Ubuntu 20.04 because it initially had build errors that I didn't take any time to fix. I recently upgraded to Ubuntu 21.04 and there are two primary issues getting Gazebo running in 21.04. The first hurdle to cross is a mismatch between protobuf versions, (read the following very closely, one misspelling was traded for a new misspelling)

   58 |   static const ::PROTOBUF_NAMESPACE_ID::internal::AuxiliaryParseTableField aux[]
      |                                                   ^~~~~~~~~~~~~~~~~~~~~~~~
      |                                                   AuxillaryParseTableField

Once the protobuf issues are resolved, (or circumvented) the next hurdle is the the change in the boost library. The following error comes up:

#pragma message: The practice of declaring the Bind placeholders (_1, _2, ...) in the global namespace is deprecated. Please use <boost/bind/bind.hpp> + using namespace boost::placeholders, or define BOOST_BIND_GLOBAL_PLACEHOLDERS to retain the current behavior.

This PR corrects that error in Ubuntu 21.04 (which installed Gazebo-11 when using the package manager to sudo apt install libgazebo9-dev but continues to work in Ubuntu 18.04.

As for the build errors on MacOS, I do not own a Mac, so I'm scratching my head on that error for right now.

As for fixing the protobuf version or downgrading my installed version, my workaround was to correct the misspelling in my locally installed gazebo msgs directory. Downgrading proved too difficult to get done today.

I hope this helps out. Let me know what other questions you have and I will see what I can learn about the MacOS build failures.

[Jaeyoung-Lim]

@mcsauder Thank you for the information.

Could you clarify whether this fix is ncessary for 20.04 as you stated in the original PR or 21.04 as you stated in the comments? I was initially a bit confused sunce Ubuntu 20.04 works without the modification that was proposed.

If this PR is un concern of 21.04, currently we do not support 21.04 as our dev environment, but since this doesnt break our primary dev environment(18.04 and 20.04) I am happy to add this fix once the MacOS failures are addressed.

@TSC21 Would you see any value on supporting 21.04 in the PX4/containers? Or would this be something that we are not interesting on supporting officially?

[mcsauder]

If this PR is un concern of 21.04, currently we do not support 21.04 as our dev environment, but since this doesnt break our primary dev environment(18.04 and 20.04) I am happy to add this fix once the MacOS failures are addressed.

@TSC21 Would you see any value on supporting 21.04 in the PX4/containers? Or would this be something that we are not interesting on supporting officially?

I agree that this is not worth addressing for Ubuntu 21.04. This is LOC in the bind.hpp file causing the error to be thrown, the change was made in 2019.

The MacOS build shows Boost 1.76, my machine is running Boost 1.74, libboost-dev is already the newest version (1.74.0.3ubuntu5). and 20.04 managed package is Boost 1.71. I think that this build failure actually begins showing up in Boost 1.73 in Linux.

I upgraded my machine in an attempt to fix a completely unrelated hardware driver issue, but because this PR is relevant to Boost 1.74 I thought it still relevant as long is it didn't break things for Ubuntu 18.04 builds. I tested that case but do not have a Mac to build on. I'm not sure why the MacOS build works with 1.76.

In light of not being able to debug the MacOS issue, I am perfectly happy to let this PR get closed, although I think it will be relevant when Ubuntu 22.04 is released next year so it might be worth hanging on to without merging for a while.

Thanks for your thoughts @Jaeyoung-Lim !

[mcsauder]

Hi again @Jaeyoung-Lim , PR #17644 appears to have some additional details on the MacOS failure in this PR.

[Jaeyoung-Lim]

@mcsauder This seems stale now, and the macOS seems to be running fine again.

I will close this for now, but please feel free to reopen if you think it is relevant

[mcsauder]

@mcsauder This seems stale now, and the macOS seems to be running fine again.

I will close this for now, but please feel free to reopen if you think it is relevant

Agreed. Thanks @Jaeyoung-Lim !