Open liamstask opened 8 years ago
That's odd, I haven't seen that error. What version of OS X are you on?
system info says, 10.11.2 (15C50)
also, not sure if it could be related, but trying to run talker
or listener
from the alpha2 binary package results in:
dyld: Library not loaded: /usr/local/lib/libcmxml.dylib
Referenced from: /Users/liam/Downloads/ros2-osx/bin/talker
Reason: image not found
Trace/BPT trap: 5
otool output:
drungus:Downloads liam$ otool -L /Users/liam/Downloads/ros2-osx/bin/talker
/Users/liam/Downloads/ros2-osx/bin/talker:
@rpath/librosidl_typesupport_opensplice_cpp.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/librmw_opensplice_cpp.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/librmw.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/librcl_interfaces__rosidl_typesupport_introspection_cpp.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/librcl_interfaces__rosidl_typesupport_opensplice_cpp.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libstd_msgs__rosidl_typesupport_introspection_cpp.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libstd_msgs__rosidl_typesupport_opensplice_cpp.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libbuiltin_interfaces__rosidl_typesupport_introspection_cpp.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libbuiltin_interfaces__rosidl_typesupport_opensplice_cpp.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libexample_interfaces__rosidl_typesupport_introspection_cpp.dylib (compatibility version 0.0.0, current version 0.0.0)
@rpath/libexample_interfaces__rosidl_typesupport_opensplice_cpp.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libcmxml.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libcommonserv.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libdcpsgapi.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libdcpssac.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libddsconfparser.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libddsconf.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libddsdatabase.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libddsi2.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libddskernel.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libddsosnet.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libddsos.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libddsserialization.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libddsuser.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libddsutil.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libdurability.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libspliced.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/lib/libdcpssacpp.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
Well the binaries aren't going to work without OpenSplice installed. I believe libcmxml.dylib
is a library which OpenSplice installs and that's what the talker
is missing in order to be run.
gotcha. let me know if there's any other info I can provide about the original build problem.
the machine i originally saw this error on is getting repaired at the moment, but on a separate machine i was able to build successfully, so appears to be something specific to that build env. i'll keep this open till i get that back and am able to investigate further.
to more clearly call out potential config/build errors, would you consider adding set -eu
or similar in minimal_build.sh
?
Ok, thanks for the update.
@gerkey The set -eu
sounds reasonable to me, but minimal_build.sh
is your script, what do you think?
We should definitely improve error-reporting in the build (or at least not continue in the face of a failed build, which is what happens now).
Unfortunately, adding set -eu
won't do the trick:
-u
prevents you from running minimal_build.sh
without any arguments to interactively pick your build type from the list, which is useful when you're not running the build from CMake.-e
causes the build to stop somewhere inside the configure
script, which gets sourced by minimal_build.sh
.To use -e
, we'd need to either restructure things to sub-shell configure
instead of sourcing it (I think that we're sourcing because we need environment variable settings from configure
to persist during the build) or fix whatever in configure
is making bash stop when -e
is set. Neither is very appealing to me, but I'd happily accept a pull request that tackles the problem. Better yet would be to replace the whole build with CMake, but that would be quite a task.
ah, so is there an existing issue that causes configure
to fail with -e
(perhaps even when everything goes according to plan)? if that's the case, it would be handy to at least flag as an issue for future investigation.
I opened #9 to track the problem.
I'm not sure what's going on inside configure
, but in a quick test that I did this morning, adding set -e
in minimal_build.sh
or directly in configure
causes an early exit with return code 1, when without that flag the build continues successfully.
looks like there's a new "feature" in OS X 10.11 (El Capitan) called System Integrity Protection that prevents DYLD_LIBRARY_PATH
from being set for sub shells. i.e., as mentioned in http://openradar.appspot.com/22807197, DYLD_LIBRARY_PATH=test bash -c 'echo $DYLD_LIBRARY_PATH'
returns empty.
there's an option to turn of this feature globally in the OS by running csrutil disable
from a recovery shell (oof). have not tried that yet but might as a stopgap.
otherwise, i think modifying the build to create binaries that describe their dependencies more clearly/explicitly might be the way to go in the future. this cmake wiki page provides a bit of background, but i'd need to read/investigate a bit further to determine a reasonable strategy.
confirmed, the build succeeds after disabling SIP system wide via csrutil disable
.
Cool, thanks for the update. I think it would be good to try and find another solution though, since presumably that protection is there for a reason.
In most of our software we prefer absolute or relative link paths to library names plus relying on the dynamic loader. I can try to figure out how to modify their build system, but honestly it's kind of a mess :smile:.
agreed - was mainly a test to see if the SIP theory was correct :D
I think I came up with a minimal work around: https://github.com/osrf/homebrew-ros2/pull/3
running one of the executables created as part of the build fails because it can't find
libddshts.dylib
(which appears to have been successfully built, just probably not in the right place). have not dug in to diagnose why it's not being found, but my build output is as follows: