Bug #3023
closedOSX 10.10: dyld Library not loaded
0%
Description
Jenkins slave OSX-10.10-ucla-pistons-10014 is having error "dyld: Library not loaded" in multiple builds.
http://jenkins.named-data.net/job/NFD/OS=OSX-10.10/2773/consoleFull
http://jenkins.named-data.net/job/NFD/OS=OSX-10.10/2758/consoleFull
http://jenkins.named-data.net/job/NFD/OS=OSX-10.10/2757/consoleFull
An error looks like:
+ ndnsec-keygen /tmp/jenkins/OSX-10.10-ucla-pistons-10014
+ ndnsec-install-cert -
dyld: Library not loaded: /usr/local/lib/libndn-cxx.0.3.3.dylib
Referenced from: /usr/local/bin/ndnsec
Reason: image not found
dyld: Library not loaded: /usr/local/lib/libndn-cxx.0.3.3.dylib
Referenced from: /usr/local/bin/ndnsec
Reason: image not found
/usr/local/bin/ndnsec-keygen: line 4: 59544 Trace/BPT trap: 5 `dirname "$0"`/ndnsec key-gen "$@"
/usr/local/bin/ndnsec-install-cert: line 4: 59546 Trace/BPT trap: 5 `dirname "$0"`/ndnsec cert-install "$@"
The pattern appears to be:
- previous build on this slave installs ndn-cxx shared library, including dynamic-linked
ndnsec
binary - current build deletes ndn-cxx shared library (with
rm -rf
), and then builds and installs ndn-cxx static library, including static-linkedndnsec
binary - current build attempts to execute
ndnsec
, and the OS somehow find the dynamic-linkedndnsec
binary, and complains the shared library object has been deleted
Updated by Alex Afanasyev over 9 years ago
I know this issue, but not planning to do anything about it. The main reason is that we use non-clean envirornment in Jenkins to optimize build times. Some projectx has been converted to build ndn-cxx as shared library and some didn't. When all projects will use the same mode (I think this is already done), the problem will no longer exist.
Updated by Junxiao Shi over 9 years ago
- Assignee deleted (
Alex Afanasyev)
I wonder why OSX is looking for shared library if ndnsec
is statically linked?
Updated by Alex Afanasyev over 9 years ago
This is something to do with the build process of ndn-cxx in /tmp. On purpose, there is no clean build of the library when library's git hash id didn't change. However, there was a reason (I forgot the details) to enable configure and build stage before installing. Because of the non-clean build, there is a shared library lingering inside build folder, which is taking precedence by the linker on OSX.
A small note. My previous attempts to force static linking on OSX revealed (at least from the sources I found) that OSX simply does not provide any mechanism to force static linking. If there are static and shared library in the same folde, the shared library will be always selected by the linker. Linux platform has special flags for this purpose, which are used by waf scripts.
Updated by Alex Afanasyev about 9 years ago
- Status changed from New to Abandoned
ndn-cxx default has been changed to shared library, so the issue should not appear any more on build bots.