embedded frameworks and dyld failure

  • This is related to a question I posted a few days ago.  Apologies if
    this has already been answered, but I am not finding it.  Running OSX
    10.4.10 on intel.

    Question:
    I am trying to bundle an app with all resources embedded.  I have
    followed steps posted here - http://developer.apple.com/documentation/
    MacOSX/Conceptual/BPFrameworks/Tasks/CreatingFrameworks.html#//
    apple_ref/doc/uid/20002258-106880-BAJJBIEF, under the Using Separate
    Xcode Projects For Each Target heading.  The app runs fine locally
    but when copied to another host (or just renaming the resource path
    locally -- effectively hiding the frameworks so that I know the app
    is loading the embedded ones) it fails.  Here's a few lines of the
    crash log:

    **********

    Host Name:      decatur
    Date/Time:      2007-09-28 04:47:01.642 -0400
    OS Version:    10.4.10 (Build 8R2232)
    Report Version: 4

    Command: EstiKit
    Path:    /Users/aarthur/Desktop/EstiKit.app/Contents/MacOS/EstiKit
    Parent:  WindowServer [59]

    Version: 0.1 (0.1)

    PID:    21368
    Thread: 0

    Exception:  EXC_BAD_ACCESS (0x0001)
    Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

    Thread 0 Crashed:
    0  <<00000000>>     0x00000000 0 + 0
    1  com.apple.myApp     0x000028a9 start + 41

    Thread 0 crashed with X86 Thread State (32-bit):
      eax: 0x00000000  ebx: 0xbffffd74  ecx: 0x90001658  edx: 0x00000002
      edi: 0xbffffd68  esi: 0xbffffd90  ebp: 0xbffffd48  esp: 0xbffffd0c
        ss: 0x0000001f  efl: 0x00010286  eip: 0x00000000  cs: 0x00000017
        ds: 0x0000001f  es: 0x0000001f  fs: 0x00000000  gs: 0x00000037

    Binary Images Description:
        0x1000 -    0x5fff com.apple.myApp 0.1    /Users/aarthur/Desktop/
    EstiKit.app/Contents/MacOS/EstiKit
        0x63000 -    0x6efff com.apple.yourcocoaframework 1.0    /Users/
    aarthur/Desktop/EstiKit.app/Contents/Frameworks/EKFormKit.framework/
    Versions/A/EKFormKit
        0xc6000 -    0xcafff com.apple.yourcocoaframework 1.0    /Users/
    aarthur/Desktop/EstiKit.app/Contents/Frameworks/GBAccess.framework/
    Versions/A/GBAccess
      0x205000 -  0x220fff com.apple.yourcocoaframework 1.0    /Users/
    aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    EstiKitModel.framework/Versions/A/EstiKitModel
      0x2d1000 -  0x2eafff com.apple.yourcocoaframework 1.0    /Users/
    aarthur/Desktop/EstiKit.app/Contents/Frameworks/GBSketchKit.framework/
    Versions/A/GBSketchKit
    0x20000000 - 0x20003fff com.apple.yourcocoaframework 1.0    /Users/
    aarthur/Desktop/EstiKit.app/Contents/Frameworks/GBAppKit.framework/
    Versions/A/GBAppKit
    0x8fe00000 - 0x8fe4afff dyld 46.12    /usr/lib/dyld

    <snip>

    0xb0000000 - 0xb000afff com.apple.yourcocoaframework 1.0    /Users/
    aarthur/Desktop/EstiKit.app/Contents/Frameworks/GBBase.framework/
    Versions/A/GBBase

    **********

    I've included the first few lines, and the last line of the log.
    Observe that dyld is loading 5 frameworks (I think), but there should
    be 6.  The missing framework is the one listed on the last line.  I
    suspect that is the source of my problem, but not exactly sure.
    Also, using otool -L on the app binary all 6 frameworks are linked:

    decatur:~/Library/EmbeddingBldDir/EstiKitHidden aarthur$ otool -L
    Development/EstiKit.app/Contents/MacOS/EstiKit
    Development/EstiKit.app/Contents/MacOS/EstiKit:
            /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
    (compatibility version 1.0.0, current version 11.0.0)
            @executable_path/../Frameworks/EKFormKit.framework/Versions/
    A/EKFormKit (compatibility version 1.0.0, current version 1.0.0)
            @executable_path/../Frameworks/EstiKitModel.framework/
    Versions/A/EstiKitModel (compatibility version 1.0.0, current version
    1.0.0)
            @executable_path/../Frameworks/GBAccess.framework/Versions/A/
    GBAccess (compatibility version 1.0.0, current version 1.0.0)
            @executable_path/../Frameworks/GBAppKit.framework/Versions/A/
    GBAppKit (compatibility version 1.0.0, current version 1.0.0)
            @executable_path/../Frameworks/GBBase.framework/Versions/A/
    GBBase (compatibility version 1.0.0, current version 1.0.0)
            @executable_path/../Frameworks/GBSketchKit.framework/
    Versions/A/GBSketchKit (compatibility version 1.0.0, current version
    1.0.0)
            /System/Library/PrivateFrameworks/ZeroLink.framework/
    Versions/A/ZeroLink (compatibility version 1.0.0, current version 1.0.0)
            /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
    current version 88.3.9)
    **********

    Can anyone please offer a clue to the solution here.  Also, is there
    a load order?  GBBase is the most basic framework and if order counts
    it should load first but it's unclear how to accomplish that.  I re-
    arranged the order in the app but kinda doubt that makes a difference.

    Best,

    --Brian
  • > Binary Images Description:
    > 0x1000 -    0x5fff com.apple.myApp 0.1    /Users/aarthur/Desktop/
    > EstiKit.app/Contents/MacOS/EstiKit
    > 0x63000 -    0x6efff com.apple.yourcocoaframework 1.0    /Users/
    > aarthur/Desktop/EstiKit.app/Contents/Frameworks/EKFormKit.framework/
    > Versions/A/EKFormKit
    > 0xc6000 -    0xcafff com.apple.yourcocoaframework 1.0    /Users/
    > aarthur/Desktop/EstiKit.app/Contents/Frameworks/GBAccess.framework/
    > Versions/A/GBAccess
    > 0x205000 -  0x220fff com.apple.yourcocoaframework 1.0    /Users/
    > aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    > EstiKitModel.framework/Versions/A/EstiKitModel
    > 0x2d1000 -  0x2eafff com.apple.yourcocoaframework 1.0    /Users/
    > aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    > GBSketchKit.framework/Versions/A/GBSketchKit
    > 0x20000000 - 0x20003fff com.apple.yourcocoaframework 1.0    /Users/
    > aarthur/Desktop/EstiKit.app/Contents/Frameworks/GBAppKit.framework/
    > Versions/A/GBAppKit
    > 0x8fe00000 - 0x8fe4afff dyld 46.12    /usr/lib/dyld

    You should change the identifiers to be unique; right now, they’re all
    com.apple.yourcocoaframework, but should be something like
    com.rr.nc.estikit.GBAppKit.

    -Ben_______________________________________________
    MacOSX-dev mailing list
    <MacOSX-dev...>
    http://www.omnigroup.com/mailman/listinfo/macosx-dev
  • Thanks for the suggestion.  I was skeptical, but at this point I'll
    try anything......, alas it did not make a difference, the results
    are exactly the same with or without specifying a CFBundleIdentifier.

    I am pretty sure of what is going wrong.  Even though I have assigned
    @executable_path/../Frameworks to every framework's Installation
    Directory config setting, somehow there's still something in the app,
    either the app itself or linked frameworks, that is loading these
    frameworks from a directory outside of the app bundle instead of from
    @executable_path/../Frameworks because when this outside folder is
    available the app runs otherwise it crashes at launch.  Why?

    **********

    Host Name:      decatur
    Date/Time:      2007-09-28 16:45:47.101 -0400
    OS Version:    10.4.10 (Build 8R2232)
    Report Version: 4

    Command: EstiKit
    Path:    /Users/aarthur/Desktop/EstiKit.app/Contents/MacOS/EstiKit
    Parent:  WindowServer [61]

    Version: 0.1 (0.1)

    PID:    2246
    Thread: 0

    Exception:  EXC_BAD_ACCESS (0x0001)
    Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

    Thread 0 Crashed:
    0  <<00000000>>     0x00000000 0 + 0
    1  com.apple.myApp     0x000028a9 start + 41

    Thread 0 crashed with X86 Thread State (32-bit):
      eax: 0x00000000  ebx: 0xbffffd74  ecx: 0x90001658  edx: 0x00000002
      edi: 0xbffffd68  esi: 0xbffffd90  ebp: 0xbffffd48  esp: 0xbffffd0c
        ss: 0x0000001f  efl: 0x00010286  eip: 0x00000000  cs: 0x00000017
        ds: 0x0000001f  es: 0x0000001f  fs: 0x00000000  gs: 0x00000037

    Binary Images Description:
        0x1000 -    0x5fff com.apple.myApp 0.1    /Users/aarthur/Desktop/
    EstiKit.app/Contents/MacOS/EstiKit
        0x9000 -    0xdfff com.gigabit.gbaccess 1.0    /Users/aarthur/
    Desktop/EstiKit.app/Contents/Frameworks/GBAccess.framework/Versions/A/
    GBAccess
      0x205000 -  0x220fff com.gigabit.estikitmodel 1.0    /Users/aarthur/
    Desktop/EstiKit.app/Contents/Frameworks/EstiKitModel.framework/
    Versions/A/EstiKitModel
      0x2d1000 -  0x2dcfff com.gigabit.ekformkit 1.0    /Users/aarthur/
    Desktop/EstiKit.app/Contents/Frameworks/EKFormKit.framework/Versions/
    A/EKFormKit
      0x334000 -  0x34dfff com.gigabit.gbsketchkit 1.0    /Users/aarthur/
    Desktop/EstiKit.app/Contents/Frameworks/GBSketchKit.framework/
    Versions/A/GBSketchKit
    0x20000000 - 0x20003fff com.gigabit.gbappkit 1.0    /Users/aarthur/
    Desktop/EstiKit.app/Contents/Frameworks/GBAppKit.framework/Versions/A/
    GBAppKit
    0x8fe00000 - 0x8fe4afff dyld 46.12    /usr/lib/dyld
    0x90000000 - 0x90171fff libSystem.B.dylib     /usr/lib/libSystem.B.dylib

    On Sep 28, 2007, at 2:17 PM, Benjamin Stiglitz wrote:

    >> Binary Images Description:
    >> 0x1000 -    0x5fff com.apple.myApp 0.1    /Users/aarthur/Desktop/
    >> EstiKit.app/Contents/MacOS/EstiKit
    >> 0x63000 -    0x6efff com.apple.yourcocoaframework 1.0    /Users/
    >> aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    >> EKFormKit.framework/Versions/A/EKFormKit
    >> 0xc6000 -    0xcafff com.apple.yourcocoaframework 1.0    /Users/
    >> aarthur/Desktop/EstiKit.app/Contents/Frameworks/GBAccess.framework/
    >> Versions/A/GBAccess
    >> 0x205000 -  0x220fff com.apple.yourcocoaframework 1.0    /Users/
    >> aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    >> EstiKitModel.framework/Versions/A/EstiKitModel
    >> 0x2d1000 -  0x2eafff com.apple.yourcocoaframework 1.0    /Users/
    >> aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    >> GBSketchKit.framework/Versions/A/GBSketchKit
    >> 0x20000000 - 0x20003fff com.apple.yourcocoaframework 1.0    /Users/
    >> aarthur/Desktop/EstiKit.app/Contents/Frameworks/GBAppKit.framework/
    >> Versions/A/GBAppKit
    >> 0x8fe00000 - 0x8fe4afff dyld 46.12    /usr/lib/dyld
    >
    > You should change the identifiers to be unique; right now, they’re
    > all com.apple.yourcocoaframework, but should be something like
    > com.rr.nc.estikit.GBAppKit.
    >
    > -Ben
  • I've experimented with so many different configuration settings I
    can't be 100% sure this was the solution, but I think what fixed this
    for me was turning off ZeroLink.

    -b

    On Sep 28, 2007, at 5:04 PM, Anthony B Arthur wrote:

    > Thanks for the suggestion.  I was skeptical, but at this point I'll
    > try anything......, alas it did not make a difference, the results
    > are exactly the same with or without specifying a CFBundleIdentifier.
    >
    > I am pretty sure of what is going wrong.  Even though I have
    > assigned @executable_path/../Frameworks to every framework's
    > Installation Directory config setting, somehow there's still
    > something in the app, either the app itself or linked frameworks,
    > that is loading these frameworks from a directory outside of the
    > app bundle instead of from @executable_path/../Frameworks because
    > when this outside folder is available the app runs otherwise it
    > crashes at launch.  Why?
    >
    > **********
    >
    > Host Name:      decatur
    > Date/Time:      2007-09-28 16:45:47.101 -0400
    > OS Version:    10.4.10 (Build 8R2232)
    > Report Version: 4
    >
    > Command: EstiKit
    > Path:    /Users/aarthur/Desktop/EstiKit.app/Contents/MacOS/EstiKit
    > Parent:  WindowServer [61]
    >
    > Version: 0.1 (0.1)
    >
    > PID:    2246
    > Thread: 0
    >
    > Exception:  EXC_BAD_ACCESS (0x0001)
    > Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
    >
    > Thread 0 Crashed:
    > 0  <<00000000>>     0x00000000 0 + 0
    > 1  com.apple.myApp     0x000028a9 start + 41
    >
    > Thread 0 crashed with X86 Thread State (32-bit):
    > eax: 0x00000000  ebx: 0xbffffd74  ecx: 0x90001658  edx: 0x00000002
    > edi: 0xbffffd68  esi: 0xbffffd90  ebp: 0xbffffd48  esp: 0xbffffd0c
    > ss: 0x0000001f  efl: 0x00010286  eip: 0x00000000  cs: 0x00000017
    > ds: 0x0000001f  es: 0x0000001f  fs: 0x00000000  gs: 0x00000037
    >
    > Binary Images Description:
    > 0x1000 -    0x5fff com.apple.myApp 0.1    /Users/aarthur/Desktop/
    > EstiKit.app/Contents/MacOS/EstiKit
    > 0x9000 -    0xdfff com.gigabit.gbaccess 1.0    /Users/aarthur/
    > Desktop/EstiKit.app/Contents/Frameworks/GBAccess.framework/Versions/
    > A/GBAccess
    > 0x205000 -  0x220fff com.gigabit.estikitmodel 1.0    /Users/aarthur/
    > Desktop/EstiKit.app/Contents/Frameworks/EstiKitModel.framework/
    > Versions/A/EstiKitModel
    > 0x2d1000 -  0x2dcfff com.gigabit.ekformkit 1.0    /Users/aarthur/
    > Desktop/EstiKit.app/Contents/Frameworks/EKFormKit.framework/
    > Versions/A/EKFormKit
    > 0x334000 -  0x34dfff com.gigabit.gbsketchkit 1.0    /Users/aarthur/
    > Desktop/EstiKit.app/Contents/Frameworks/GBSketchKit.framework/
    > Versions/A/GBSketchKit
    > 0x20000000 - 0x20003fff com.gigabit.gbappkit 1.0    /Users/aarthur/
    > Desktop/EstiKit.app/Contents/Frameworks/GBAppKit.framework/Versions/
    > A/GBAppKit
    > 0x8fe00000 - 0x8fe4afff dyld 46.12    /usr/lib/dyld
    > 0x90000000 - 0x90171fff libSystem.B.dylib     /usr/lib/libSystem.B.dylib
    >
    > On Sep 28, 2007, at 2:17 PM, Benjamin Stiglitz wrote:
    >
    >>> Binary Images Description:
    >>> 0x1000 -    0x5fff com.apple.myApp 0.1    /Users/aarthur/Desktop/
    >>> EstiKit.app/Contents/MacOS/EstiKit
    >>> 0x63000 -    0x6efff com.apple.yourcocoaframework 1.0    /Users/
    >>> aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    >>> EKFormKit.framework/Versions/A/EKFormKit
    >>> 0xc6000 -    0xcafff com.apple.yourcocoaframework 1.0    /Users/
    >>> aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    >>> GBAccess.framework/Versions/A/GBAccess
    >>> 0x205000 -  0x220fff com.apple.yourcocoaframework 1.0    /Users/
    >>> aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    >>> EstiKitModel.framework/Versions/A/EstiKitModel
    >>> 0x2d1000 -  0x2eafff com.apple.yourcocoaframework 1.0    /Users/
    >>> aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    >>> GBSketchKit.framework/Versions/A/GBSketchKit
    >>> 0x20000000 - 0x20003fff com.apple.yourcocoaframework 1.0    /Users/
    >>> aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    >>> GBAppKit.framework/Versions/A/GBAppKit
    >>> 0x8fe00000 - 0x8fe4afff dyld 46.12    /usr/lib/dyld
    >>
    >> You should change the identifiers to be unique; right now, they’re
    >> all com.apple.yourcocoaframework, but should be something like
    >> com.rr.nc.estikit.GBAppKit.
    >>
    >> -Ben
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
  • I have found that the exact same issue occurs for Mail Plugins that I
    have written. I was trying to use RBSplitView as a framework from
    within a plugin and at run time it would always complain about that
    framework not being there. I could not get the linker to change where
    it would look at run time no matter what I did. In the end I used the
    static library supplied for RBSplitView.

    I would love to know how to solve this one as well.

    scott
    --
    "Reality is that which, when you stop believing in it, doesn't go away."
    Philip K. Dick
    --
    scott little
    <slittle...>
    --
    sadly no music right now: iTunes is Stopped

    On 28 Sep, 2007, at 23:04, Anthony B Arthur wrote:

    > Thanks for the suggestion.  I was skeptical, but at this point I'll
    > try anything......, alas it did not make a difference, the results
    > are exactly the same with or without specifying a CFBundleIdentifier.
    >
    > I am pretty sure of what is going wrong.  Even though I have
    > assigned @executable_path/../Frameworks to every framework's
    > Installation Directory config setting, somehow there's still
    > something in the app, either the app itself or linked frameworks,
    > that is loading these frameworks from a directory outside of the
    > app bundle instead of from @executable_path/../Frameworks because
    > when this outside folder is available the app runs otherwise it
    > crashes at launch.  Why?
    >
    > **********
    >
    > Host Name:      decatur
    > Date/Time:      2007-09-28 16:45:47.101 -0400
    > OS Version:    10.4.10 (Build 8R2232)
    > Report Version: 4
    >
    > Command: EstiKit
    > Path:    /Users/aarthur/Desktop/EstiKit.app/Contents/MacOS/EstiKit
    > Parent:  WindowServer [61]
    >
    > Version: 0.1 (0.1)
    >
    > PID:    2246
    > Thread: 0
    >
    > Exception:  EXC_BAD_ACCESS (0x0001)
    > Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000
    >
    > Thread 0 Crashed:
    > 0  <<00000000>>     0x00000000 0 + 0
    > 1  com.apple.myApp     0x000028a9 start + 41
    >
    > Thread 0 crashed with X86 Thread State (32-bit):
    > eax: 0x00000000  ebx: 0xbffffd74  ecx: 0x90001658  edx: 0x00000002
    > edi: 0xbffffd68  esi: 0xbffffd90  ebp: 0xbffffd48  esp: 0xbffffd0c
    > ss: 0x0000001f  efl: 0x00010286  eip: 0x00000000  cs: 0x00000017
    > ds: 0x0000001f  es: 0x0000001f  fs: 0x00000000  gs: 0x00000037
    >
    > Binary Images Description:
    > 0x1000 -    0x5fff com.apple.myApp 0.1    /Users/aarthur/Desktop/
    > EstiKit.app/Contents/MacOS/EstiKit
    > 0x9000 -    0xdfff com.gigabit.gbaccess 1.0    /Users/aarthur/
    > Desktop/EstiKit.app/Contents/Frameworks/GBAccess.framework/Versions/
    > A/GBAccess
    > 0x205000 -  0x220fff com.gigabit.estikitmodel 1.0    /Users/aarthur/
    > Desktop/EstiKit.app/Contents/Frameworks/EstiKitModel.framework/
    > Versions/A/EstiKitModel
    > 0x2d1000 -  0x2dcfff com.gigabit.ekformkit 1.0    /Users/aarthur/
    > Desktop/EstiKit.app/Contents/Frameworks/EKFormKit.framework/
    > Versions/A/EKFormKit
    > 0x334000 -  0x34dfff com.gigabit.gbsketchkit 1.0    /Users/aarthur/
    > Desktop/EstiKit.app/Contents/Frameworks/GBSketchKit.framework/
    > Versions/A/GBSketchKit
    > 0x20000000 - 0x20003fff com.gigabit.gbappkit 1.0    /Users/aarthur/
    > Desktop/EstiKit.app/Contents/Frameworks/GBAppKit.framework/Versions/
    > A/GBAppKit
    > 0x8fe00000 - 0x8fe4afff dyld 46.12    /usr/lib/dyld
    > 0x90000000 - 0x90171fff libSystem.B.dylib     /usr/lib/libSystem.B.dylib
    >
    > On Sep 28, 2007, at 2:17 PM, Benjamin Stiglitz wrote:
    >
    >>> Binary Images Description:
    >>> 0x1000 -    0x5fff com.apple.myApp 0.1    /Users/aarthur/Desktop/
    >>> EstiKit.app/Contents/MacOS/EstiKit
    >>> 0x63000 -    0x6efff com.apple.yourcocoaframework 1.0    /Users/
    >>> aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    >>> EKFormKit.framework/Versions/A/EKFormKit
    >>> 0xc6000 -    0xcafff com.apple.yourcocoaframework 1.0    /Users/
    >>> aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    >>> GBAccess.framework/Versions/A/GBAccess
    >>> 0x205000 -  0x220fff com.apple.yourcocoaframework 1.0    /Users/
    >>> aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    >>> EstiKitModel.framework/Versions/A/EstiKitModel
    >>> 0x2d1000 -  0x2eafff com.apple.yourcocoaframework 1.0    /Users/
    >>> aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    >>> GBSketchKit.framework/Versions/A/GBSketchKit
    >>> 0x20000000 - 0x20003fff com.apple.yourcocoaframework 1.0    /Users/
    >>> aarthur/Desktop/EstiKit.app/Contents/Frameworks/
    >>> GBAppKit.framework/Versions/A/GBAppKit
    >>> 0x8fe00000 - 0x8fe4afff dyld 46.12    /usr/lib/dyld
    >>
    >> You should change the identifiers to be unique; right now, they’re
    >> all com.apple.yourcocoaframework, but should be something like
    >> com.rr.nc.estikit.GBAppKit.
    >>
    >> -Ben
    >
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
    >
  • Am 29.09.2007 um 11:53 schrieb scott little:
    > I have found that the exact same issue occurs for Mail Plugins that
    > I have written. I was trying to use RBSplitView as a framework from
    > within a plugin and at run time it would always complain about that
    > framework not being there. I could not get the linker to change
    > where it would look at run time no matter what I did. In the end I
    > used the static library supplied for RBSplitView.
    >
    > I would love to know how to solve this one as well.

      @executable_path literally means the path of the *executable*
    launched. It won't point to the loader of a particular library, it
    will point to the root application in whose memory space all those
    libraries were launched. You'd need something like an @loader_path if
    you want to embed one framework in the other. Since, AFAIK, that
    isn't available yet, you may have to change the path of a bundle that
    is loaded by another bundle so it points at the correct path
    *relative to the application*, not relative to its containing framework.

      Does that help in any way? You'd definitely want to make sure you
    have unique identifiers, too, because frameworks get loaded based on
    their identifier, I think, so it may be possible that if one
    framework got loaded with a particular identifier, the OS may not
    actually load the others.

      Also, make sure your Cocoa class names are unique across *all*
    frameworks. There's only a single namespace for classes, so if you
    load a framework with a class named the same as one already loaded,
    your new class will not be loaded, and your code will use the already
    loaded class instead, which may implement a completely different API.

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
  • Uli,

    Thanks for this information, it helped a lot, because in searching
    for other @executable_path options (which I was aware of from the
    first time I looked at this) I found that the Tiger Release Notes
    actually DO provide a @loader_path!

    http://developer.apple.com/releasenotes/DeveloperTools/RN-dyld/

    Works fine now. Note that I have already taken into account the other
    points that you mention here.

    scott
    --
    "Only the curious will learn and only the resolute overcome the
    obstacles to learning. The quest quotient has always excited me more
    than the intelligence quotient."
    Eugene S. Wilson
    --
    scott little
    <slittle...>
    --
    sadly no music right now: iTunes is Stopped

    On 29 Sep, 2007, at 19:51, Uli Kusterer wrote:

    > Am 29.09.2007 um 11:53 schrieb scott little:
    >> I have found that the exact same issue occurs for Mail Plugins
    >> that I have written. I was trying to use RBSplitView as a
    >> framework from within a plugin and at run time it would always
    >> complain about that framework not being there. I could not get the
    >> linker to change where it would look at run time no matter what I
    >> did. In the end I used the static library supplied for RBSplitView.
    >>
    >> I would love to know how to solve this one as well.
    >
    > @executable_path literally means the path of the *executable*
    > launched. It won't point to the loader of a particular library, it
    > will point to the root application in whose memory space all those
    > libraries were launched. You'd need something like an @loader_path
    > if you want to embed one framework in the other. Since, AFAIK, that
    > isn't available yet, you may have to change the path of a bundle
    > that is loaded by another bundle so it points at the correct path
    > *relative to the application*, not relative to its containing
    > framework.
    >
    > Does that help in any way? You'd definitely want to make sure you
    > have unique identifiers, too, because frameworks get loaded based
    > on their identifier, I think, so it may be possible that if one
    > framework got loaded with a particular identifier, the OS may not
    > actually load the others.
    >
    > Also, make sure your Cocoa class names are unique across *all*
    > frameworks. There's only a single namespace for classes, so if you
    > load a framework with a class named the same as one already loaded,
    > your new class will not be loaded, and your code will use the
    > already loaded class instead, which may implement a completely
    > different API.
    >
    > Cheers,
    > -- M. Uli Kusterer
    > http://www.zathras.de
    >
    >
    >
    >
  • Am 01.10.2007 um 11:38 schrieb scott little:
    > Thanks for this information, it helped a lot, because in searching
    > for other @executable_path options (which I was aware of from the
    > first time I looked at this) I found that the Tiger Release Notes
    > actually DO provide a @loader_path!

      Ah, good to know. I used the name because I remembered I'd read it
    somewhere, but didn't say more because I wasn't sure whether it had
    been in Leopard :-)

    Cheers,
    -- M. Uli Kusterer
    http://www.zathras.de
previous month september 2007 next month
MTWTFSS
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
Go to today