Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Example Compile Error in Mac OS Mojave #1200

Closed
shbang91 opened this issue Nov 29, 2018 · 9 comments · Fixed by ros/console_bridge#60
Closed

Example Compile Error in Mac OS Mojave #1200

shbang91 opened this issue Nov 29, 2018 · 9 comments · Fixed by ros/console_bridge#60
Labels
status: in-progress

Comments

@shbang91
Copy link

shbang91 commented Nov 29, 2018 •
edited
Loading

Hello,
I am working on Mac OS Mojave with DART 6.5.0
I just go to the

examples/atlasSimbicon
mkdir build & cd build
cmake .. & make

and getting the following error

ld: library not found for -lconsole_bridge
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [atlasSimbicon] Error 1
make[1]: *** [CMakeFiles/atlasSimbicon.dir/all] Error 2
make: *** [all] Error 2

I think this issue is related to the version of Mac OS.
Do you have a plan to fix this?
@scpeters
Copy link
Collaborator

On mojave, the build tools do not search /usr/local by default any longer. The example cmake file may need to be updated.

@shbang91
Copy link
Author

Thanks a lot!

@scpeters
Copy link
Collaborator

actually, this looks related to ros/console_bridge#52

@scpeters scpeters mentioned this issue Nov 29, 2018
Closed
@scpeters scpeters mentioned this issue Dec 12, 2018
Merged
@scpeters
Copy link
Collaborator

I think this will be fixed by ros/console_bridge#60

jslee02 added a commit that referenced this issue Jan 5, 2019
@jslee02
Call find_package() for DART's dependency libraries
23b596d 
when a downstream library imports DART. This is to import targets of the dependency libraries (if available) so that the dependency library is properly linked when the library is a target but not an absolute path to the library. Without this, simply linking to a dependency target will fail as #1200.
@jslee02 jslee02 mentioned this issue Jan 6, 2019
Merged
1 task
@jslee02
Copy link
Member

jslee02 commented Jan 6, 2019 •
edited
Loading

@scpeters Thanks for the fix! However, the fix didn't work for me. I think it fails to load console_bridge (and even console_bridge::console_bridge) because the target is not imported by just loading DARTConfig.cmake. Instead, DARTConfig.cmake only store the target name in DART_LIBRARIES without importing the target actually.

It seems #1209 works for with and without ros/console_bridge#60. I'm down with adding the namespace by the way.

@shbang91 I reopened this issue because it's not actually resolved yet. Also, thanks for the report.

@jslee02 jslee02 reopened this Jan 6, 2019
jslee02 added a commit that referenced this issue Jan 8, 2019
@jslee02
Import dependency targets when loading DARTConfig.cmake (#1209)
ef20d1a 
Currently, the transitive dependencies of DART are propagated by using CMake variables. For example, all the dependency libraries are stored in `DART_LIBRARIES`, which will be defined by loading `DARTConfig.cmake` through calling `find_package(DART)` in a downstream project. 

However, this approach can fail to load the dependency. The items in `DART_LIBRARIES` can be either of the path to a library file or a target. Path items work fine (as long as the path is correct), but not targets because the downstream project don't know how to import the target only from the target name. This PR fixes it by letting `DARTConfig.cmake` loading the dependency targets by calling `find_packages()` for them. This approach should work as long as all the upstream dependencies loading relevant targets subsequently.

In this PR, the new change is only applied for loading `urdfdom` to quickly fix #1200, but this should be applied to all other transitive dependencies in future PRs.

***

**Before merging a pull request**

- [x] Set version target by selecting a milestone on the right side
@scpeters scpeters reopened this Jan 9, 2019
@scpeters
Copy link
Collaborator

scpeters commented Jan 9, 2019

Thanks @jslee02; I thought the target namespace was the problem, but I guess it's an issue in dart. Yes, #1209 seems to fix it.

@jslee02
Copy link
Member

jslee02 commented Jan 9, 2019

@scpeters Thanks for the confirmation. I think I learned a lot about target including target namespace!

Closing this issue as it's resolved. @shbang91 Please let us know if this is still persistent for you.

@jslee02 jslee02 closed this as completed Jan 9, 2019
@scpeters
Copy link
Collaborator

scpeters commented Jan 9, 2019

It's resolved on the release-6.7 branch, but it won't be fully resolved for downstream users until it's released in homebrew. Do you have a planned date for the 6.7 release?

@jslee02
Copy link
Member

jslee02 commented Jan 9, 2019 •
edited
Loading

Sure. I plan to release 6.7 once #1212 is merged, and I think #1212 is almost ready.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
status: in-progress
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

cmake: export target with namespace scpeters/console_bridge
3 participants
@scpeters @jslee02 @shbang91