-
-
Notifications
You must be signed in to change notification settings - Fork 4
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.
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
Fix macOS build #3
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
@conda-forge-admin, please rerender |
…da-forge-pinning 2021.03.21.19.58.38
@conda-forge-admin, please rerender |
…da-forge-pinning 2021.03.21.19.58.38
Hey @traversaro - I think this has sth to do with https://github.com/conda-forge/libignition-rendering4-feedstock as all tests fail which pull in https://github.com/conda-forge/libignition-rendering4-feedstock but none of the others. Isuru on gitter reckons that sth links to the system blas instead of conda blas. |
New suspicion: System OpenGL is pulled in - I think it should find the conda one instead. |
I may be wrong, but I think that on macOS and on Windows using the system OpenGL is expected. |
Probably we can try https://github.com/jtanx/lddx to find who is linking blas. |
The
However, I can't find anything related to vecLib or libBLAS, I wonder if this is caused by something that is |
Now that I think about it, most of OGRE functionalities is part of plugins that are dynically loaded. The loaded plugins are https://github.com/ignitionrobotics/ign-rendering/blob/a5f00f91f507cf9cc14134f2fca0f03c4a99a7cc/ogre/src/OgreRenderEngine.cc#L438 , we should check them with lddx . |
The only thing relevant in the lddx output seems to be that
By inspecting the build scripts, it seems that ogre 1.12 links (see https://github.com/OGRECave/ogre/blob/a4a70c5fe2e9d38896781c8a9cbccfb78a1de62c/RenderSystems/GLSupport/CMakeLists.txt#L66 ):
while 1.10 (that has been extensively tested via RViz and Gazebo) has (https://github.com/OGRECave/ogre/blob/v1.10.12/RenderSystems/GLSupport/CMakeLists.txt#L110 and https://github.com/OGRECave/ogre/blob/v1.10.12/RenderSystems/GL/CMakeLists.txt#L85):
I do not know if this could be the explanation, but a possible strategy could be to stick to Ogre 1.10 even for the ignition libraries. |
Related PR: https://github.com/OGRECave/ogre/pull/1513/files . The ogre vendored version in rviz for ros2 (https://github.com/ros2/rviz/blob/ros2/rviz_ogre_vendor/CMakeLists.txt#L155) is 1.12.1 and does not have this change, and if RViz for ros2 is working this may be another indication that it could be related. |
Given all the analysis, I think that one out of |
Agreed - in the short term pinning to 1.10.* is fine, and considering that rviz(1) probably won't get patched to properly work with ogre 1.12.*, we should consider building two variants in the mid to long-term. |
btw this might not be immediately helpful but using this github action one can get a ssh connection to a github worker. https://github.com/marketplace/actions/debugging-with-tmate I have a build locally that has the same failure. I've tried to find who links BLAS/Accelerate but couldn't really find much more than what you already know. I can try to dig deeper... or if you have an idea, let me know and I can poke around! Also entering the directory and running the unit test directly seems to work fine. |
I found one more data point. we can export
and then running the binary directly gives:
I wonder if we shoudl link to all these system libraries / frameworks ... |
Cool! I remember a similar thing but was a repo on its own, this one seems useful to debug existing workflows instead.
I would try to recompile Ogre 1.12 but removing |
@traversaro - I suggest to close this PR, and focus on #5 instead. |
Done! |
Checklist
0
(if the version changed)conda-smithy
(Use the phrase@conda-forge-admin, please rerender
in a comment in this PR for automated rerendering)