linking to assimp fails on mac 10.10 about geometric_shapes

[argrento]

I have the same issue with ROS Kinetic, OSX 10.11.6 and assimp-3.3.1.
Location of lib: /usr/local/lib/libassimp.dylib

Fix:

1. Open ~/ros_catkin_ws/build_isolated/geometric_shapes/CMakeFiles/geometric_shapes.dir/link.txt
2. Replace -lassimp with /usr/local/lib/libassimp.dylib.

[mikepurvis]

Okay, can confirm that I see the issue on my El Cap machine. With the following CMakeLists.txt:

find_package(assimp)
message("xxxx ${ASSIMP_LIBRARIES}")

find_library(
    assimp_LIBRARIES
    NAMES assimp
)
message("yyyy ${assimp_LIBRARIES}")

I have this output:

$ cmake .
xxxx assimp
yyyy /usr/local/lib/libassimp.dylib

So find_library does the right thing, but assimp's hardcoded library name most definitely doesn't.

[pgorczak]

On a related note, the assimp version check in CMakeLists.txt failed for me on Yosemite with the latest brew assimp (also with --HEAD which is 3.1.1)

[davetcoleman]

This issue is old - was a solution found or is it still a problem? Can it be closed?

[de-vri-es]

geometric_shapes simply uses a system provided cmake module or otherwise pkg-config. If that results in linking errors it sounds like there is a problem with the way Assimp is packaged by homebrew.

[robobit]

I had the same issue with Kinetic, OS X 10.12.5 and assimp 3.3.1.
I used the fix by @argrento which worked for me.

[mikepurvis]

Just to follow this up here with some relevant links:

Homebrew formula: https://github.com/Homebrew/homebrew-core/blob/master/Formula/assimp.rb

Find module from upstream: https://github.com/assimp/assimp/blob/master/cmake-modules/Findassimp.cmake

Certainly the find_library portion of the module looks pretty bog-standard to me:

https://github.com/assimp/assimp/blob/92046319be744fa514d643bab38c57b2c5fbae24/cmake-modules/Findassimp.cmake#L61-L65

Then again, there's also this other config module in the upstream, which is way more sketchy:

https://github.com/assimp/assimp/blob/92046319be744fa514d643bab38c57b2c5fbae24/assimp-config.cmake.in#L50

All in all, the cmake strategy in assimp looks rather haphazard...

[v4hn]

I'll close this.

All further problems with this should be discussed over at assimp:
assimp/assimp#1517