#2 hardcoded path in binary

open
nobody
None
5
2009-05-04
2009-05-04
Anonymous
No

dyld: Library not loaded: /Users/treaves/Library/Frameworks/Log4Cocoa.framework/Versions/A/Log4Cocoa thrown when running application that references Log4Cocoa.framework

Discussion

  • Timothy Reaves
    Timothy Reaves
    2009-07-20

    I believe the latest build corrects this.

     
  • I also encountered dynamic loader errors using Log4Cocoa build form source or as a framework download. I debugged the problem a few days ago, but did not get around to post it. I used the beta2 source and farmework download.

    I added the Log4Cocoa project based on the description in the readme. I still had some problems and read the framework chapter in the XCode help (XCode 3.1 Developer Tools Library, Creating a framework, Embedding a Private Framework in Your Application Bundle, Using Separate Xcode Projects For Each Target). I found two additional steps:
    - Set the value of the Installation Directory build setting to @executable_path/../Frameworks.
    - Modify the Build Products Path setting for both the application and framework targets so that they use the same build directory. You need to modify each target in their original Xcode project file.
    After that I was able to build and debug my project.

    Later I tried to open the application from the finder which results in an unexpected application error. Opening it from the command line using the "open" command resulted in an "LSOpenFromURLSpec() failed with error -10810". Opening it from the command line by running the executable from within the Content/MacOS directory showed a dynamic linker error for the Log4Cocoa.framework.

    The error showed that the dynamic linker tried to load the library contained in the framework from /Users/Martin/Library/Frameworks/Log4Cocoa.framework and not from MyApp/Contents//Frameworks/Log4Cocoa.framework. Having had no idea how the dynamic loader and the build settings of the framework and my project fit together I spend some time on this. My understanding was that the executable file contains a path were the framework library is expected and that this path is copied from the library file during build time.
    I used "otool -L" to look at the path information in my executable file (MyApp/Contents/MacOs/MyApp) and found it contained "/Users/Martin/Library/Frameworks/Log4Cocoa.framework/Versions/A/Log4Cocoa". Then I checked the library in the framework and found "/Users/Martin/Library/Frameworks/Log4Cocoa.framework/Versions/A/Log4Cocoa". Based on the documentation I was expecting "@executable_path/../Frameworks/Log4Cocoa.framework/Versions/A/Log4Cocoa". Checking some other installed application's private frameworks their path always starts with "@executable_path/../Frameworks" (e.g. @executable_path/../Frameworks/Adium.framework/Versions/A/Adium).
    I also checked the compiled version of the framework that is for download on Sourceforge. It also contains an absolute library path.

    As far as I understand the documentation using the "Installation Directory" build setting with "@executable_path/../Frameworks" is supposed to do the trick. But obviously this was not the case. I played around and found that I needed to set the "Dynamic Library Install Name" build setting to "@executable_path/../Frameworks/Log4Cocoa.framework/Versions/A/Log4Cocoa" or to make it more flexible "@executable_path/../Frameworks/$(PROJECT_NAME).framework/Versions/${FRAMEWORK_VERSION}/$(PROJECT_NAME)".

    After changing the setting the framework as well as the executable contained the correct path. The application could be started from XCode, the finder and the command line.

     
  • I tested this with the beta3 source. The framework still builds with an absolute path. The compiled beta3 version also contains an absolute path (/Frameworks/Log4Cocoa.framework/Versions/A/Log4Cocoa).