Drosera Launcher repeatedly crash on launch with the "webkit failed to open correctly" message. Here is the crash log: 2007-01-14 12:54:32.090 DroseraLauncher[266] Unable to load nib file: MainMenu, exiting dyld: Symbol not found: _WebScriptDebugServerProcessNameKey Referenced from: /Applications/Drosera.app/Contents/Resources/Drosera.app/Contents/MacOS/Drosera Expected in: /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit" Bypassing Droseralauncher give same result. NOTE: Replacing the"/System/Library/Frameworks/WebKit.framework" with the "WebKit.framework" found in Webkit.app prevent an other application (Overflow) to launch. Here is the Overflow's crash log: "Link (dyld) error: Library not loaded: /Users/mrowe/Documents/Source/SVN/WebKit-Nightlies/WebKitBuild/Release/JavaScriptCore.framework/Versions/A/JavaScriptCore Referenced from: /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit Reason: image not found" Who is user "mrowe"? -Fabrice
Fabrice, which nightly are you using? This sounds like some kind of build/packaging failure in the nightly build.
Thanks for the quick reply... Too bad I just threw everything to the trash so I can't tell you... Let say I downloaded the nightly four years ago. I will try again with a fresh download in few minutes and let you know asap. (sorry for my approximative English) -fabrice
Build is 420+, same as before. Webkit works fine but Drosera still won't launch. DroseraLauncher log: "2007-01-14 15:34:27.723 DroseraLauncher[850] Unable to load nib file: MainMenu, exiting dyld: Symbol not found: _WebScriptDebugServerProcessNameKey Referenced from: /Applications/Drosera.app/Contents/Resources/Drosera.app/Contents/MacOS/Drosera Expected in: /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit" Drosera log: Link (dyld) error: Symbol not found: _WebScriptDebugServerProcessNameKey Referenced from: /Applications/Drosera.app/Contents/Resources/Drosera.app/Contents/MacOS/Drosera Expected in: /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit" Deleted "org.webkit.nightly.WebKit.plist" and "org.webkit.drosera.launcher.plist" without success. I run Mac Os 10.4.8. I have no Safari addition currently active. If you haven't heard about this besides from me it may not be a "bug" I'm afraid... -fabrice
Sorry, I should have read the error message closer. What's happening is that Drosera trying to load the WebKit framework from Mac OS X 10.4.8 instead of the nightly WebKit. > Expected in: /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit" I don't think the problem is that the 'mrowe' paths appear in the shared library load paths, but that the extra 'libgcc_s.1.dylib' appears in the load path. What is that? $ otool -L /Volumes/WebKit/Drosera.app/Contents/Resources/Drosera.app/Contents/MacOS/Drosera /Volumes/WebKit/Drosera.app/Contents/Resources/Drosera.app/Contents/MacOS/Drosera: /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 11.0.0) /Users/mrowe/Documents/Source/SVN/WebKit-Nightlies/WebKitBuild/Release/WebKit.framework/Versions/A/WebKit (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) /Users/mrowe/Documents/Source/SVN/WebKit-Nightlies/WebKitBuild/Release/JavaScriptCore.framework/Versions/A/JavaScriptCore (compatibility version 1.0.0, current version 1.0.0) /Users/mrowe/Documents/Source/SVN/WebKit-Nightlies/WebKitBuild/Release/WebCore.framework/Versions/A/WebCore (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.4) BTW, confirmed failure to load with r18843.
(In reply to comment #4) > BTW, confirmed failure to load with r18843. Confirmed that Drosera in nightly r18794 works fine. Drosera in nightlies r18828, r18836 and r18843 are broken. Fabrice, as a workaround please use Drosera from r18794. I don't believe any major changes have been made to it between those revisions.
No more luck with build r18794 ... Here is what I get when launching Drosera from Terminal: "$ /Applications/Drosera.app/Contents/Resources/Drosera.app/Contents/MacOS/Drosera dyld: Library not loaded: /Users/mrowe/Documents/Source/SVN/WebKit-Nightlies/WebKitBuild/Release/JavaScriptCore.framework/Versions/A/JavaScriptCore Referenced from: /Applications/Drosera.app/Contents/Resources/Drosera.app/Contents/MacOS/Drosera Reason: image not found Trace/BPT trap" And here is the "otool -L" command output: "$ otool -L /Applications/Drosera.app/Contents/Resources/Drosera.app/Contents/MacOS/Drosera /Applications/Drosera.app/Contents/Resources/Drosera.app/Contents/MacOS/Drosera: /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 11.0.0) /Users/mrowe/Documents/Source/SVN/WebKit-Nightlies/WebKitBuild/Release/WebKit.framework/Versions/A/WebKit (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) /Users/mrowe/Documents/Source/SVN/WebKit-Nightlies/WebKitBuild/Release/JavaScriptCore.framework/Versions/A/JavaScriptCore (compatibility version 1.0.0, current version 1.0.0) /Users/mrowe/Documents/Source/SVN/WebKit-Nightlies/WebKitBuild/Release/WebCore.framework/Versions/A/WebCore (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.3.4)" I will test again with other builds, may be compile my own, etc... If you know some useful tests I could perform with otool, class-dump, GDB let me know... -fabrice
Oooops! Forget it! I just tried again and it works now! Same r18794 from dmg! What does it means??? Anyway, I assume that we can say r18794 actually works in 10.4.8. Thanks for the help... -fabrice
This is very odd. Over the weekend I changed how I built the nightlies very slightly: From ./WebKitTools/Scripts/build-webkit DEPLOYMENT_POSTPROCESSING=YES STRIP_INSTALLED_PRODUCT=YES ARCHS="ppc i386" SDKROOT_ppc="/Developer/SDKs/MacOSX10.4u.sdk" to: ./WebKitTools/Scripts/build-webkit DEPLOYMENT_POSTPROCESSING=YES STRIP_INSTALLED_PRODUCT=YES ARCHS="ppc i386" SDKROOT="/Developer/SDKs/MacOSX10.4u.sdk" MAC_OS_X_VERSION_MAX_ALLOWED=MAC_OS_X_VERSION_10_4 MACOSX_DEPLOYMENT_TARGET=10.4 (with similar arguments for build-launcher-app which builds Drosera). I get the feeling that using the SDK to build Drosera is causing these problems, as it appears to be loading the system version of WebKit rather than the bundled framework. Dave, what makes you think that libgcc_s.1.dylib is the problem?
(In reply to comment #8) > Dave, what makes you think that libgcc_s.1.dylib is the problem? Simply because it was one of the differences between the working builds of Drosera and the broken builds of Drosera.
It turns out the issue was related to some changes I had made to the application launcher. It performs a little bit of magic to convince the operating system that the application you double-click is the application that ends up being launched. In reality, it's a different application (in case of WebKit.app it's actually Safari.app, in the case of Drosera.app, it's actually Drosera.app/Contents/Resources/Drosera.app). In the process of making these changes, I forgot to update Drosera's launcher which was causing something in AppKit to look for bundle resources in the wrong place. The key error message here was actually: DroseraLauncher[266] Unable to load nib file: MainMenu, exiting Please note that it is a *really really* bad idea to mess with anything under /System, and that definitely includes replacing /System/Library/Frameworks/WebKit.framework with a custom version. That said, the latest nightly build (currently r18847) should now work correctly. I'm leaving this bug open until I commit the relevant changes to SVN.
The changes related to this were landed in r18849.
Everything seems fine so far from r18847 to r18850 included. -fabrice
Closing since Drosera has been replaced by the new Web Inspector debugger. Moving to the New Bugs component so the Drosera component can be closed and removed.