Project

General

Profile

Actions
Copy link

Bug #3023

closed

OSX 10.10: dyld Library not loaded

Added by Junxiao Shi over 9 years ago. Updated over 9 years ago.

Status:
Abandoned
Priority:
High
Assignee:
-
Category:
Build
Target version:
v0.4
Start date:
07/08/2015
Due date:
% Done:

0%

Estimated time:

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:

  1. previous build on this slave installs ndn-cxx shared library, including dynamic-linked ndnsec binary
  2. current build deletes ndn-cxx shared library (with rm -rf), and then builds and installs ndn-cxx static library, including static-linked ndnsec binary
  3. current build attempts to execute ndnsec, and the OS somehow find the dynamic-linked ndnsec binary, and complains the shared library object has been deleted
Actions
Copy link
 #1

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.

Actions
Copy link
 #2

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?

Actions
Copy link
 #3

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.

Actions
Copy link
 #4

Updated by Alex Afanasyev over 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.

Actions
Copy link

Also available in: Atom PDF