[Webkit-unassigned] [Bug 83105] New: figure out how to export webcore symbols from webkit.dll properly

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=83105

           Summary: figure out how to export webcore symbols from
                    webkit.dll properly
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Platform
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: dpranke at chromium.org
                CC: fishd at chromium.org, tony at chromium.org,
                    abarth at webkit.org, jamesr at chromium.org,
                    rvargas at chromium.org, scottmg at chromium.org


We've stumbled onto an issue in attempting to export a symbol out of chromium/public/WebMediaStreamSourcesRequest.h, which is part of webcore_platform now.

Since WebMediaStreamSourcesRequest.cpp is not referenced by anything in WebKit directly (apparently), it looks like we run into an issue on windows where, when building webkit.dll, we think the file is dead/unused code, and it isn't linked into the DLL.

We attempted to work around this by enabling ULDI for webkit.dll in bug 83068, but that appears to have caused other weird issues downstream in chromium, so we reverted that.

For now we've hacked around it in http://trac.webkit.org/changeset/113105 by forcing a reference from WebKit.cpp to the file, but this is not a good nor scalable solution.

It seems like the "correct" solution is to not build webcore_platform as a .lib at all, but to include the objects directly into the link of webkit.lib/webkit.dll (this is basically what I did for content.dll). However, we suspect that we'll hit the 128KB command line limit for the linker, like we did when we tried this w/ chrome.dll, and what caused Scott to write 'supalink' to break up the command line.

So, it's not clear what the best way forward is ... thoughts?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.