Fix Error: No file at @loader_path/libboost_system-mt.dylib #4190

Ignoring the framework does not seem to cause any problems in the final build, but I'm not 100% percent sure what @loader_path means, so someone more experienced should confirm this.

@theuni can you please comment here

Problem here seems to be that it thinks boost is a framework when it isn't. I would think that this would cause a runtime failure, since boost_system isn't being packaged. If it doesn't, it must mean that boost_system is already packaged and then it tries it again for some reason as a framework and fails. Could you give a few details on your boost install please?

• How is it installed
• otool -LD libboost_system-mt.dylib

boost was installed via homebrew (bottled).

$ cd /usr/local/lib && otool -LD libboost_system-mt.dylib
libboost_system-mt.dylib:
    /usr/local/lib/libboost_system-mt.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 1197.1.1)

Hmm, do you have a boost framework around somewhere else? Could you please also paste the output of otool -LD on the bitcoin-qt binary, before running the deployment script?

$ otool -LD src/qt/bitcoin-qt
src/qt/bitcoin-qt:
    /usr/local/lib/libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/local/lib/libboost_filesystem.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/local/lib/libboost_program_options-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/local/lib/libboost_thread-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/local/lib/libboost_chrono-mt.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/local/lib/QtGui.framework/Versions/4/QtGui (compatibility version 4.8.0, current version 4.8.6)
    /usr/local/lib/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.8.0, current version 4.8.6)
    /usr/local/lib/QtCore.framework/Versions/4/QtCore (compatibility version 4.8.0, current version 4.8.6)
    /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1056.13.0)
    /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0)
    /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1265.20.0)
    /usr/local/lib/libqrencode.3.dylib (compatibility version 8.0.0, current version 8.3.0)
    /usr/local/lib/libprotobuf.8.dylib (compatibility version 9.0.0, current version 9.0.0)
    /usr/local/lib/libdb_cxx-4.8.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/local/lib/libminiupnpc.9.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/local/opt/openssl/lib/libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
    /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.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 1197.1.1)
    /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
    /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 59.0.0)
    /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 855.16.0)

I set some breakpoints in the macdeploy script and found out that the @loader_path/libboost_system-mt.dylib framework gets brought in as a dependency when calling getFrameworks with /usr/local/lib/libboost_thread-mt.dylib. Not sure if that helps.

I don't know anything about MacOSX building. @theuni does it make sense to merge this?

ping @theuni should we merge this or are you working on another fix?

I've repro'd the issue here, will post a fix.

@federicobond Could you please give this a shot? If it works fine, you can just update this PR with it.

diff --git a/contrib/macdeploy/macdeployqtplus b/contrib/macdeploy/macdeployqtplus
index ce4169a..b710806 100755
--- a/contrib/macdeploy/macdeployqtplus
+++ b/contrib/macdeploy/macdeployqtplus
@@ -211,6 +211,7 @@ def getFrameworks(binaryPath, verbose):

     libraries = []
     for line in otoolLines:
+        line = line.replace("@loader_path",os.path.dirname(binaryPath))
         info = FrameworkInfo.fromOtoolLibraryLine(line.strip())
         if info is not None:
             if verbose >= 3:
@@ -307,7 +308,7 @@ def deployFrameworks(frameworks, bundlePath, binaryPath, strip, verbose, deploym
         if deploymentInfo.qtPath is None and framework.isQtFramework():
             deploymentInfo.detectQtPath(framework.frameworkDirectory)

-        if framework.installName.startswith("@executable_path"):
+        if framework.installName.startswith("@executable_path") or framework.installName.startswith(bundlePath):
             if verbose >= 2:
                 print framework.frameworkName, "already deployed, skipping."
             continue

Explanation: @loader_path is used when a lib depends on another lib relative to the original location. In this case, the boost libs require the base boost libs (chrono -> system, for example).

If @loader_path paths are skipped, they're not guaranteed to be packaged... only if we explicitly link to them (which we currently do for boost). The above change makes it so that these libs are correctly packaged if they haven't been already.

@theuni works fine. PR updated.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p4190_502972f16bae79cf025bf9b63ec8276bc4a236bb/ for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

@federicobond Thanks. And thanks for tracking down the culprit. @laanwj good to go now.

@theuni thanks!