Bug 41610 - Duplicate Symbol definition warnings .
Summary: Duplicate Symbol definition warnings .
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-05 05:35 PDT by Jeremy Moskovich
Modified: 2011-03-28 14:33 PDT (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeremy Moskovich 2010-07-05 05:35:26 PDT
It looks like some Cocoa calls can load the system copy of WebKit.  For OS X applications that embed their own copy of WebKit, this can lead to errors like the following:

objc[1841]: Class WKAppKitDrawDecoyWindow is implemented in both /Applications/Google Chrome.app/Contents/MacOS/../Versions/5.0.375.38/Google Chrome Framework.framework/Google Chrome Framework and 
/System/Library/Frameworks/WebKit.framework/Versions/A/WebKit. One of the two will be used. Which one is undefined.

Searching for the error appears to show that Chromium isn't the only Mac application suffering from this issue:
* http://forums.steampowered.com/forums/showthread.php?t=1311095
* http://forums.adobe.com/thread/665225?tstart=0

Looking at the symbols defined in the WebKitSystemInterface object files, it appears that they contain Objective C classes and categories. Is it safe to have multiple and possibly diverging versions of these loaded into the binary at the same time?
Comment 1 Mark Rowe (bdash) 2010-07-05 14:49:11 PDT
From what I can see the latest WKSI no longer statically defines a class named WKAppKitDrawDecoyWindow, it creates registers one at runtime if no class of that name has already been registered.  Therefore the message you quote will not be generated if a more recent WKSI is used.
Comment 2 Avi Drissman 2010-07-05 18:37:03 PDT
(In reply to comment #1)
> From what I can see the latest WKSI no longer statically defines a class named WKAppKitDrawDecoyWindow, it creates registers one at runtime if no class of that name has already been registered.  Therefore the message you quote will not be generated if a more recent WKSI is used.

Even without that message, we still have class compatibility issues.

If the WKSI checks by name, then we have the problem where one version of the WKSI tries to use the decoy window class generated by a different version of the WKSI. Is the decoy window class compatible enough to handle that?