Bug 12263 - Drosera won't launch in Tiger due to dependency on /usr/lib/libgcc_s.1.dylib (nightlies r18828, r18836, r18843)
Summary: Drosera won't launch in Tiger due to dependency on /usr/lib/libgcc_s.1.dylib ...
Status: CLOSED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 420+
Hardware: Macintosh PowerPC OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-14 04:29 PST by fabrice
Modified: 2008-05-17 09:56 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description fabrice 2007-01-14 04:29:35 PST
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
Comment 1 David Kilzer (:ddkilzer) 2007-01-14 05:24:31 PST
Fabrice, which nightly are you using?

This sounds like some kind of build/packaging failure in the nightly build.

Comment 2 fabrice 2007-01-14 06:18:08 PST
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
Comment 3 fabrice 2007-01-14 06:55:41 PST
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
Comment 4 David Kilzer (:ddkilzer) 2007-01-14 09:02:40 PST
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.

Comment 5 David Kilzer (:ddkilzer) 2007-01-14 09:10:21 PST
(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.

Comment 6 fabrice 2007-01-14 13:06:53 PST
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
Comment 7 fabrice 2007-01-14 13:23:38 PST
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
Comment 8 Mark Rowe (bdash) 2007-01-14 16:18:18 PST
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?
Comment 9 David Kilzer (:ddkilzer) 2007-01-14 16:20:50 PST
(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.
Comment 10 Mark Rowe (bdash) 2007-01-14 16:48:03 PST
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.
Comment 11 Mark Rowe (bdash) 2007-01-14 17:10:54 PST
The changes related to this were landed in r18849.
Comment 12 fabrice 2007-01-14 23:05:20 PST
Everything seems fine so far from r18847 to r18850 included.

-fabrice
Comment 13 Timothy Hatcher 2008-05-17 09:56:01 PDT
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.