Re: Link (dyld) error: image not found (QuickTime.framework)
Re: Link (dyld) error: image not found (QuickTime.framework)
- Subject: Re: Link (dyld) error: image not found (QuickTime.framework)
- From: Eric Albert <email@hidden>
- Date: Fri, 16 Dec 2005 11:31:01 -0800
On Dec 16, 2005, at 11:12 AM, Jonathan del Strother wrote:
On 16 Dec 2005, at 17:51, Eric Albert wrote:
On Dec 16, 2005, at 1:10 AM, Jonathan del Strother wrote:
I've had a couple of users send me crash reports like the one
pasted below. Apparently my app loads fine, but later just bombs
out complaining that it can't find Quicktime. They say that
Quicktime player and everything else works fine - any suggestions
what might cause this?
Command: CoverFlow
Path: /Applications/CoverFlow.app/Contents/MacOS/CoverFlow
Parent: WindowServer [64]
Link (dyld) error:
image not found /System/Library/Frameworks/QuickTime.framework/
QuickTime
This is interesting. Typically applications link against the
actual binary file inside each framework. For example, here's
what QuickTime Player links against:
Ithilien:~> otool -L /Applications/QuickTime\ Player.app/Contents/
MacOS/QuickTime\ Player | grep QuickTime
/Applications/QuickTime Player.app/Contents/MacOS/QuickTime Player:
/System/Library/Frameworks/QuickTime.framework/Versions/A/
QuickTime (compatibility version 1.0.0, current version 11.0.0)
Note that it's "QuickTime.framework/Versions/A/QuickTime". The
path in your crash log is normally a symlink to the binary in
Versions/A, but it isn't technically required. I wonder if it's
missing on those users' systems. But what I'm more curious about
is how you built an application in the first place which linked
against the symlink version instead of the actual binary.
Very good question. I just dropped QuickTime.framework into
XCode's "Link Binary to Libraries" build step. During the build
stage there's a -framework Quicktime argument in there - is there
any way to find exactly what path gcc is evaluating that to?
Only by running otool -L on the resulting binary. From what you've
shown, though, it sounds like your system's OK.
I'd suggest running otool -L against your binary and seeing which
path you get.
$ otool -L CoverFlow
CoverFlow:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
(compatibility version 1.0.0, current version 11.0.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/
OpenGL (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/QuickTime.framework/Versions/A/
QuickTime (compatibility version 1.0.0, current version 6.0.0)
/System/Library/Frameworks/AGL.framework/Versions/A/AGL
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/
A/CoreServices (compatibility version 1.0.0, current version 18.0.0)
/System/Library/Frameworks/QTKit.framework/Versions/A/QTKit
(compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/
Carbon (compatibility version 2.0.0, current version 128.0.0)
@executable_path/../Frameworks/libid3-3.8.3.0.0.dylib
(compatibility version 4.0.0, current version 4.0.0)
@executable_path/../Frameworks/libz.1.0.0.dylib
(compatibility version 2.0.0, current version 2.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/
Security (compatibility version 1.0.0, current version 24844.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.3.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libmx.A.dylib (compatibility version 1.0.0,
current version 92.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.1.2)
Looks good to me. So the question is, how are those users coming
up with the odd paths?
Yeah, it looks good to me, too. libz is part of the OS, by the way. :)
And you might want to take a look at the QuickTime framework on
your build system (or in the SDK you're using) and make sure it
has a symlink there rather than an actual binary.
My Quicktime installation appears normal -
Yep...it sure does.
I'm currently trying to get hold of someone who's seeing these
problems, to see what their Quicktime.framework folder looks like,
but no luck just yet...
That'll probably be the best option, but even so I can't imagine how
dyld could point to that location when your app isn't pointing to
it. I'd also suggest grabbing a copy of their copy of your
application, running otool -L on it, and seeing what the results are.
-Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden