FindIgnOGRE2: prefer versioned component libraries

[scpeters]

Both ogre1.9 and ogre2.1 install component libraries named
libOgreOverlay. For ogre1.9, an unversioned symbolic link is
installed directly into the lib folder, while in our debian
libogre-2.1-dev and brew ogre2.1 packages, an unversioned symbolic
link is installed in lib/OGRE-2.1.

This find module uses find_library to find Ogre component libraries
with HINTS pointing to the lib/OGRE-2.1 subfolder, which is helpful
but limited because the CMAKE_PREFIX_PATH is searched before
the HINTS. When building ignition-rendering with homebrew, the
CMAKE_PREFIX_PATH may include /usr/local, which causes the
libOgreOverlay library from ogre1.9 to be found before the
version from ogre2.1.

On macOS, the following are in /usr/local/lib:

/usr/local/lib/libOgreOverlay.1.9.0.dylib
/usr/local/lib/libOgreOverlay.2.1.0.dylib
/usr/local/lib/libOgreOverlay.dylib (sym-link to 1.9.0)

This causes find_library to prefer a library name with the version
appended before the suffix, while still accepting unversioned names
if a versioned name is not found.

I believe this will fix gazebosim/gz-sensors#62

[scpeters]

As it happens, the problem is reproducible in Linux if you build ign-rendering with CMAKE_PREFIX_PATH=/usr and have both versions of ogre installed.

[scpeters]

the changed code is in a if (NOT WIN32) block, so I don't think it's urgent to test on windows, though it would be good to test in a colcon workspace on both Linux and macOS

[scpeters]

here's a yaml workspace file if you want to test with a colcon workspace (remember to set CMAKE_PREFIX_PATH=/usr/local on macOS to reproduce the problematic homebrew configuration, or CMAKE_PREFIX_PATH=/usr on Linux):

• https://raw.githubusercontent.com/ignition-tooling/gazebodistro/d35e21a2400f745c672db5e99bd42e1b9e29a4d6/ign-sensors4.yaml

to test on macOS, checkout the following branch and brew install ignition-rendering4:

• https://github.com/osrf/homebrew-simulation/compare/find_ogre2_overlay_brew

use otool -L /usr/local/lib/libignition-rendering4-ogre2.dylib | grep Overlay to confirm which library is linked

it would be nice if I could configure a CI job to run these tests, but I don't think we currently have that capability

[iche033]

I did some tests with the scpeters:find_ogre2_overlay_brew branch in a colcon workspace. I found that With CMAKE_PREFIX_PATH set to /usr, I noticed libOgreOverlay.so is missing when I do ldd. Maybe I'm doing something different?

Here's the cmd I used:

colcon build --merge-install  --cmake-args -DCMAKE_PREFIX_PATH=/usr --packages-up-to ignition-rendering4

My ldd result:

ldd ./install/lib/libignition-rendering4-ogre2.so | grep Ogre
	libOgreMain.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreMain.so.2.1.0 (0x00007f8b6d86c000)
	libOgreHlmsPbs.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreHlmsPbs.so.2.1.0 (0x00007f8b6ca9c000)
	libOgreHlmsUnlit.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreHlmsUnlit.so.2.1.0 (0x00007f8b6c87c000)

But if I build everything without setting CMAKE_PREFIX_PATH, I do see libOgreOverlay linked properly:

ldd ./install/lib/libignition-rendering4-ogre2.so | grep Ogre
	libOgreMain.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreMain.so.2.1.0 (0x00007f7de9191000)
	libOgreHlmsPbs.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreHlmsPbs.so.2.1.0 (0x00007f7de8386000)
	libOgreHlmsUnlit.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreHlmsUnlit.so.2.1.0 (0x00007f7de8166000)
	libOgreOverlay.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreOverlay.so.2.1.0 (0x00007f7de7f06000)

[scpeters]

I did some tests with the scpeters:find_ogre2_overlay_brew branch in a colcon workspace. I found that With CMAKE_PREFIX_PATH set to /usr, I noticed libOgreOverlay.so is missing when I do ldd. Maybe I'm doing something different?

Here's the cmd I used:

colcon build --merge-install  --cmake-args -DCMAKE_PREFIX_PATH=/usr --packages-up-to ignition-rendering4

My ldd result:

ldd ./install/lib/libignition-rendering4-ogre2.so | grep Ogre
	libOgreMain.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreMain.so.2.1.0 (0x00007f8b6d86c000)
	libOgreHlmsPbs.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreHlmsPbs.so.2.1.0 (0x00007f8b6ca9c000)
	libOgreHlmsUnlit.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreHlmsUnlit.so.2.1.0 (0x00007f8b6c87c000)

But if I build everything without setting CMAKE_PREFIX_PATH, I do see libOgreOverlay linked properly:

ldd ./install/lib/libignition-rendering4-ogre2.so | grep Ogre
	libOgreMain.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreMain.so.2.1.0 (0x00007f7de9191000)
	libOgreHlmsPbs.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreHlmsPbs.so.2.1.0 (0x00007f7de8386000)
	libOgreHlmsUnlit.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreHlmsUnlit.so.2.1.0 (0x00007f7de8166000)
	libOgreOverlay.so.2.1.0 => /usr/lib/x86_64-linux-gnu/libOgreOverlay.so.2.1.0 (0x00007f7de7f06000)

yeah, for Linux I basically confirmed that the bug is reproducible, but I don't have a fix for it. it seems to be unable to find libOgreOverlay in either case when CMAKE_PREFIX_PATH=/usr. I can try to fix that too, but I think it's less urgent than the fix for macOS since we have working debs on Linux, but our homebrew bottles are broken.

I'll look into this further, but I think there's value in merging this even without fixing Linux

[scpeters]

I think we could first call find_library with NO_CMAKE_ENVIRONMENT_PATH so that the HINTS would be preferred first and then call it a second time without that option. My priority with this PR isn't to fix Linux, but rather to fix macOS since our bottles are currently broken. I'll open an issue describing the problem on Linux

[iche033]

My priority with this PR isn't to fix Linux, but rather to fix macOS since our bottles are currently broken. I'll open an issue describing the problem on Linux

sounds good!

[iche033]

changes look good to me.

[scpeters]

I'll open an issue describing the problem on Linux

I filed #126 to document the problem on Linux