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: Jonathan del Strother <email@hidden>
- Date: Fri, 16 Dec 2005 19:12:53 +0000
Thanks for the response -
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?
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?
Assuming you get the path that you're seeing in the crash logs,
I'd suggest looking at your build process and seeing how you link
against QuickTime and whether you're running install_name_tool or
anything like that on the build product to change your link paths.
My build process is very vanilla - I'm not doing anything non-
standard to the executable. install_name_tool was used on the libid3
& libz libraries that I link to, but that's about it.
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 -
$ ls -l /System/Library/Frameworks/QuickTime.framework
total 24
lrwxr-xr-x 1 root wheel 24 Nov 10 22:41 Headers@ -> Versions/
Current/Headers
lrwxr-xr-x 1 root wheel 26 Oct 13 10:35 QuickTime@ -> Versions/
Current/QuickTime
lrwxr-xr-x 1 root wheel 26 Oct 13 10:35 Resources@ -> Versions/
Current/Resources
drwxr-xr-x 4 root wheel 136 Oct 13 10:35 Versions/
$ ls -l /System/Library/Frameworks/QuickTime.framework/Versions/
total 8
drwxr-xr-x 5 root wheel 170 Nov 30 16:14 A/
lrwxr-xr-x 1 root wheel 1 Oct 13 10:35 Current@ -> A
$ ls -l /System/Library/Frameworks/QuickTime.framework/Versions/A
total 6824
drwxr-xr-x 34 root wheel 1156 Nov 10 22:41 Headers/
-rwxr-xr-x 1 root wheel 3489940 Nov 30 16:14 QuickTime*
drwxr-xr-x 20 root wheel 680 Oct 13 10:35 Resources/
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...
Any other thoughts in the meantime?
Thanks for your help,
Jon
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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