181500 2018-01-10 15:16:18 -0800 [Win] WebKitLegacy should be a dll, not a static library. 2018-01-16 10:29:34 -0800 1 1 1 Unclassified WebKit WebKit Misc. WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 pvollan pvollan achristensen bfulgham commit-queue mcatanzaro webkit-bug-importer oldest_to_newest 1387894 0 pvollan 2018-01-10 15:16:18 -0800 Currently, WebKitLegacy is built as a static library. 1387895 1 webkit-bug-importer 2018-01-10 15:17:53 -0800 <rdar://problem/36418479> 1387918 2 330981 pvollan 2018-01-10 15:51:27 -0800 Created attachment 330981 Patch 1388072 3 330981 commit-queue 2018-01-10 20:57:55 -0800 Comment on attachment 330981 Patch Clearing flags on attachment: 330981 Committed r226758: <https://trac.webkit.org/changeset/226758> 1388073 4 commit-queue 2018-01-10 20:57:57 -0800 All reviewed patches have been landed. Closing bug. 1388229 5 pvollan 2018-01-11 07:52:40 -0800 Thanks for reviewing! 1389587 6 mcatanzaro 2018-01-16 10:01:23 -0800 I was going to say: "This isn't right, those are both the default library types for those libs now. I think this patch is a no-op, unless the Windows port is setting these types to undesired values somewhere else." and then revert this patch. But, is it possible that you're not running the toplevel CMakeLists.txt at all, for internal builds? That is where the default library types are defined. If so, how is that code supposed to get run? And how does OptionsWin get run instead? 1389588 7 mcatanzaro 2018-01-16 10:04:29 -0800 Note: I removed these from OptionsWin.cmake in r226266, when I changed the default library types, because they had become redundant, and it seemed clearer to set library types only for those libraries that deviate from the WebKit project defaults on a given port. Or so I thought. Maybe the Apple ports need to be special, if they don't run the toplevel CMakeLists.txt. 1389600 8 achristensen 2018-01-16 10:29:34 -0800 Only in the internal build, there is no top-level CMakeLists.txt. There is only what is in Source/cmake and what is in the currently building directory, like what is in Source/JavaScriptCore for example. This change did not fix anything on public bots because they use the top level CMakeLists.txt but it fixed the internal build. 330981 2018-01-10 15:51:27 -0800 2018-01-10 20:57:55 -0800 Patch bug-181500-20180111005127.patch text/plain 1087 pvollan SW5kZXg6IENoYW5nZUxvZwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBDaGFuZ2VMb2cJKHJldmlzaW9uIDIyNjc0 MSkKKysrIENoYW5nZUxvZwkod29ya2luZyBjb3B5KQpAQCAtMSwzICsxLDE0IEBACisyMDE4LTAx LTEwICBQZXIgQXJuZSBWb2xsYW4gIDxwdm9sbGFuQGFwcGxlLmNvbT4KKworICAgICAgICBbV2lu XSBXZWJLaXRMZWdhY3kgc2hvdWxkIGJlIGEgZGxsLCBub3QgYSBzdGF0aWMgbGlicmFyeS4KKyAg ICAgICAgaHR0cHM6Ly9idWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTE4MTUwMAorCisg ICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIFNldCBXZWJLaXRM ZWdhY3kgbGlicmFyeSB0eXBlIHRvIHNoYXJlZC4KKworICAgICAgICAqIFNvdXJjZS9jbWFrZS9P cHRpb25zV2luLmNtYWtlOgorCiAyMDE4LTAxLTA1ICBGdWppaSBIaXJvbm9yaSAgPEhpcm9ub3Jp LkZ1amlpQHNvbnkuY29tPgogCiAgICAgICAgIFJFR1JFU1NJT04ocjIyNjMwNilbV2luXVtDTWFr ZV0gVW5uZWNlc3NhcnkgcmVjb21waWxhdGlvbnMgdHJpZ2dlcmVkIGJ5IHVuY29uZGl0aW9uYWxs eSBjb3BpZWQgaGVhZGVyIGZpbGVzIG9mIERlcml2ZWRTb3VyY2VzCkluZGV4OiBTb3VyY2UvY21h a2UvT3B0aW9uc1dpbi5jbWFrZQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBTb3VyY2UvY21ha2UvT3B0aW9uc1dp bi5jbWFrZQkocmV2aXNpb24gMjI2NzIwKQorKysgU291cmNlL2NtYWtlL09wdGlvbnNXaW4uY21h a2UJKHdvcmtpbmcgY29weSkKQEAgLTE0MSw1ICsxNDEsNyBAQCBlbmRpZiAoKQogc2V0KFBPUlQg V2luKQogc2V0KEphdmFTY3JpcHRDb3JlX0xJQlJBUllfVFlQRSBTSEFSRUQpCiBzZXQoV1RGX0xJ QlJBUllfVFlQRSBTSEFSRUQpCitzZXQoUEFMX0xJQlJBUllfVFlQRSBTVEFUSUMpCitzZXQoV2Vi S2l0TGVnYWN5X0xJQlJBUllfVFlQRSBTSEFSRUQpCiAKIGZpbmRfcGFja2FnZShJQ1UgUkVRVUlS RUQpCg==