Bug 46762 - WebKit.gyp always builds as static_library, breaking shared chromium builds
Summary: WebKit.gyp always builds as static_library, breaking shared chromium builds
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-28 15:59 PDT by Matt Mueller
Modified: 2010-10-04 21:22 PDT (History)
4 users (show)

See Also:

Attachments
use 'webkit_target_type': '<(library)' when inside_chromium_build (1.81 KB, patch)
2010-09-28 16:05 PDT, Matt Mueller 		no flags Details | Formatted Diff | Diff
Patch (1.96 KB, patch)
2010-09-29 15:25 PDT, Matt Mueller 		no flags Details | Formatted Diff | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Matt Mueller 2010-09-28 15:59:55 PDT 
WebKit gets unconditionally built statically, regardless what the library setting of Chromium build is.  Since libwebkit is linked in multiple libraries in chrome, this causes issues with initializers and finalizers getting called multiple times.  Building webkit as a shared library fixes this issue.

I saw http://trac.webkit.org/changeset/50985 which changed it to be built statically under chromium and shared otherwise, and http://trac.webkit.org/changeset/53001 which caused it to always be built statically.   The reasoning isn't entirely clear to me, but it seems that, at least when building under chromium, we should just use the <(library) setting to build webkit.

Chromium bugs caused by this:
http://code.google.com/p/chromium/issues/detail?id=47575
http://code.google.com/p/chromium/issues/detail?id=47979
Comment 1 Matt Mueller 2010-09-28 16:05:48 PDT 
Created attachment 69124 [details]
use 'webkit_target_type': '<(library)' when inside_chromium_build
Comment 2 WebKit Commit Bot 2010-09-29 12:33:57 PDT 
Comment on attachment 69124 [details]
use 'webkit_target_type': '<(library)' when inside_chromium_build

Rejecting patch 69124 from commit-queue.

Failed to run "['./WebKitTools/Scripts/webkit-patch', '--status-host=queues.webkit.org', 'apply-attachment', '--force-clean', '--non-interactive', '--quiet', 69124]" exit_code: 2
Cleaning working directory
Updating working directory
Logging in as commit-queue@webkit.org...
Fetching: https://bugs.webkit.org/attachment.cgi?id=69124&action=edit
Fetching: https://bugs.webkit.org/show_bug.cgi?id=46762&ctype=xml
Processing 1 patch from 1 bug.
Processing patch 69124 from bug 46762.
Failed to run "[u'/Projects/CommitQueue/WebKitTools/Scripts/svn-apply', u'--reviewer', u'Darin Fisher', u'--force']" exit_code: 1

Full output: http://queues.webkit.org/results/4225010
Comment 3 Matt Mueller 2010-09-29 15:25:14 PDT 
Created attachment 69259 [details]
Patch
Comment 4 Matt Mueller 2010-09-29 15:28:29 PDT 
I think that failed because the patch didn't have full paths, since I just generated it from a regular chromium checkout.  Generated a new patch using a full webkit checkout, hopefully this one will work correctly.
Comment 5 Matt Mueller 2010-10-04 13:51:43 PDT 
ping, mind taking another quick look?
Comment 6 WebKit Commit Bot 2010-10-04 21:21:54 PDT 
Comment on attachment 69259 [details]
Patch

Clearing flags on attachment: 69259

Committed r69067: <http://trac.webkit.org/changeset/69067>
Comment 7 WebKit Commit Bot 2010-10-04 21:22:01 PDT 
All reviewed patches have been landed.  Closing bug.