Bug 41610 – Duplicate Symbol definition warnings .

• Status: NEW
• Component: WebKit API

[Jeremy Moskovich]

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?

[Mark Rowe (bdash)]

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.

[Avi Drissman]

(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?