Fix macOS/windows tests that failed to load library #60
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Steve Peters <scpeters@openrobotics.org>
|
I'm going to rebase and then mark this ready for review |
scpeters
force-pushed
the
macos_workflow_4
branch
from
51bfd87
to
cba3058
Compare
scpeters
changed the title
This fixes tests on macOS and windows that were failing to find and/or load a sensor component library. In windows CI and the macOS workflow (which runs `make test` before `make install`) tests were failing with the message "Unable to find sensor plugin path". This is fixed by setting the IGN_PLUGIN_PATH in cmake to the build folder containing the compiled plugins. In the macOS jenkins build (which runs `make test` after `make install`) tests were failing with the message "SDF sensor type does not match template type". It was difficult to track down, but it appears to be caused by a failure to properly dlopen all the shared libraries linked by the component plugins when a test finds an installed component library, rather than one from the build folder. It is fixed by setting DYLD_LIBRARY_PATH to include the location of the installed libraries. Fixes gazebosim#4. Signed-off-by: Steve Peters <scpeters@openrobotics.org>
They don't work on windows, so just depend on the environment variables set in cmake instead. Signed-off-by: Steve Peters <scpeters@openrobotics.org>
scpeters
force-pushed
the
macos_workflow_4
branch
from
cba3058
to
23c249a
Compare
|
I've updated the pull request description, and this is now ready for review. All windows tests are fixed, and most macOS tests are fixed; there are just a few remaining complaining about "lazy symbol binding failed" in ogre. I'll open a separate issue for those. |
|
this also fixes #49 |
This was referenced Nov 10, 2020
I opened #62 to track those remaining test failures |
chapulina
added
macOS
chapulina
approved these changes
Nov 11, 2020
iche033
approved these changes
Nov 11, 2020
Merged
scpeters
added a commit
to scpeters/ign-sensors
that referenced
this pull request
Nov 19, 2020
* Add workflow for macos-latest * Set test env to help find plugins This fixes tests on macOS and windows that were failing to find and/or load a sensor component library. In windows CI and the macOS workflow (which runs `make test` before `make install`) tests were failing with the message "Unable to find sensor plugin path". This is fixed by setting the IGN_PLUGIN_PATH in cmake to the build folder containing the compiled plugins. In the macOS jenkins build (which runs `make test` after `make install`) tests were failing with the message "SDF sensor type does not match template type". It was difficult to track down, but it appears to be caused by a failure to properly dlopen all the shared libraries linked by the component plugins when a test finds an installed component library, rather than one from the build folder. It is fixed by setting DYLD_LIBRARY_PATH to include the location of the installed libraries. Fixes gazebosim#4. * Remove redundant AddPluginPaths calls from tests They don't work on windows, so just depend on the environment variables set in cmake instead. Signed-off-by: Steve Peters <scpeters@openrobotics.org>
scpeters
added a commit
to scpeters/ign-sensors
that referenced
this pull request
Nov 20, 2020
* Add workflow for macos-latest * Set test env to help find plugins This fixes tests on macOS and windows that were failing to find and/or load a sensor component library. In windows CI and the macOS workflow (which runs `make test` before `make install`) tests were failing with the message "Unable to find sensor plugin path". This is fixed by setting the IGN_PLUGIN_PATH in cmake to the build folder containing the compiled plugins. In the macOS jenkins build (which runs `make test` after `make install`) tests were failing with the message "SDF sensor type does not match template type". It was difficult to track down, but it appears to be caused by a failure to properly dlopen all the shared libraries linked by the component plugins when a test finds an installed component library, rather than one from the build folder. It is fixed by setting DYLD_LIBRARY_PATH to include the location of the installed libraries. Fixes gazebosim#4. * Remove redundant AddPluginPaths calls from tests They don't work on windows, so just depend on the environment variables set in cmake instead. Signed-off-by: Steve Peters <scpeters@openrobotics.org>
azeey
pushed a commit
to azeey/gz-sensors
that referenced
this pull request
Feb 18, 2021
* Add workflow for macos-latest * Set test env to help find plugins This fixes tests on macOS and windows that were failing to find and/or load a sensor component library. In windows CI and the macOS workflow (which runs `make test` before `make install`) tests were failing with the message "Unable to find sensor plugin path". This is fixed by setting the IGN_PLUGIN_PATH in cmake to the build folder containing the compiled plugins. In the macOS jenkins build (which runs `make test` after `make install`) tests were failing with the message "SDF sensor type does not match template type". It was difficult to track down, but it appears to be caused by a failure to properly dlopen all the shared libraries linked by the component plugins when a test finds an installed component library, rather than one from the build folder. It is fixed by setting DYLD_LIBRARY_PATH to include the location of the installed libraries. Fixes gazebosim#4. * Remove redundant AddPluginPaths calls from tests They don't work on windows, so just depend on the environment variables set in cmake instead. Signed-off-by: Steve Peters <scpeters@openrobotics.org>
azeey
pushed a commit
to azeey/gz-sensors
that referenced
this pull request
Feb 18, 2021
Fix macOS/windows tests that failed to load library (gazebosim#60) * Add workflow for macos-latest * Set test env to help find plugins This fixes tests on macOS and windows that were failing to find and/or load a sensor component library. In windows CI and the macOS workflow (which runs `make test` before `make install`) tests were failing with the message "Unable to find sensor plugin path". This is fixed by setting the IGN_PLUGIN_PATH in cmake to the build folder containing the compiled plugins. In the macOS jenkins build (which runs `make test` after `make install`) tests were failing with the message "SDF sensor type does not match template type". It was difficult to track down, but it appears to be caused by a failure to properly dlopen all the shared libraries linked by the component plugins when a test finds an installed component library, rather than one from the build folder. It is fixed by setting DYLD_LIBRARY_PATH to include the location of the installed libraries. Fixes gazebosim#4. * Remove redundant AddPluginPaths calls from tests They don't work on windows, so just depend on the environment variables set in cmake instead. Signed-off-by: Steve Peters <scpeters@openrobotics.org>
azeey
pushed a commit
that referenced
this pull request
Feb 18, 2021
Fix macOS/windows tests that failed to load library (#60) * Add workflow for macos-latest * Set test env to help find plugins This fixes tests on macOS and windows that were failing to find and/or load a sensor component library. In windows CI and the macOS workflow (which runs `make test` before `make install`) tests were failing with the message "Unable to find sensor plugin path". This is fixed by setting the IGN_PLUGIN_PATH in cmake to the build folder containing the compiled plugins. In the macOS jenkins build (which runs `make test` after `make install`) tests were failing with the message "SDF sensor type does not match template type". It was difficult to track down, but it appears to be caused by a failure to properly dlopen all the shared libraries linked by the component plugins when a test finds an installed component library, rather than one from the build folder. It is fixed by setting DYLD_LIBRARY_PATH to include the location of the installed libraries. Fixes #4. * Remove redundant AddPluginPaths calls from tests They don't work on windows, so just depend on the environment variables set in cmake instead. Signed-off-by: Steve Peters <scpeters@openrobotics.org>
Merged
chapulina
added a commit
that referenced
this pull request
Mar 18, 2021
* Prepare fo 3.2.0 release (#94) Signed-off-by: Nate Koenig <nate@openrobotics.org> Co-authored-by: Nate Koenig <nate@openrobotics.org> * Backport #60 from ign-sensors4 Fix macOS/windows tests that failed to load library (#60) * Add workflow for macos-latest * Set test env to help find plugins This fixes tests on macOS and windows that were failing to find and/or load a sensor component library. In windows CI and the macOS workflow (which runs `make test` before `make install`) tests were failing with the message "Unable to find sensor plugin path". This is fixed by setting the IGN_PLUGIN_PATH in cmake to the build folder containing the compiled plugins. In the macOS jenkins build (which runs `make test` after `make install`) tests were failing with the message "SDF sensor type does not match template type". It was difficult to track down, but it appears to be caused by a failure to properly dlopen all the shared libraries linked by the component plugins when a test finds an installed component library, rather than one from the build folder. It is fixed by setting DYLD_LIBRARY_PATH to include the location of the installed libraries. Fixes #4. * Remove redundant AddPluginPaths calls from tests They don't work on windows, so just depend on the environment variables set in cmake instead. Signed-off-by: Steve Peters <scpeters@openrobotics.org> * 👩🌾 Clear Windows warnings (backport #58) (#102) Signed-off-by: Louise Poubel <louise@openrobotics.org> Co-authored-by: Alejandro Hernández Cordero <ahcorde@gmail.com> * Master branch updates (#106) Signed-off-by: Louise Poubel <louise@openrobotics.org> Co-authored-by: Nate Koenig <nkoenig@users.noreply.github.com> Co-authored-by: Nate Koenig <nate@openrobotics.org> Co-authored-by: Steve Peters <scpeters@openrobotics.org> Co-authored-by: Alejandro Hernández Cordero <ahcorde@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a GitHub actions workflow that uses macOS Catalina to help debug the
UNIT_Lidar_TESTfailures reported in #4. It turns out that all the windows test failures and most on macOS are caused by a failure to load sensor component libraries properly and can be fixed by properly setting environment variables for the tests.In windows CI and the macOS workflow (which runs
make testbeforemake install) tests were failing with the message "Unable to find sensor plugin path". This is fixed by setting theIGN_PLUGIN_PATHin cmake to the build folder containing the compiled plugins.In the macOS jenkins build (which runs
make testaftermake install) tests were failing with the message "SDF sensor type does not match template type". It was difficult to track down, but it appears to be caused by a failure to properly dlopen all the shared libraries linked by the component plugins when a test finds an installed component library, rather than one from the build folder. It is fixed by settingDYLD_LIBRARY_PATHto include the location of the installed libraries.There were also some
AddPluginPathscalls in integration tests that didn't work on all platforms and are now redundant after setting the environment variables in cmake, so I've removed those lines from the tests.