[Webkit-unassigned] [Bug 104773] [EFL] Split WebCore into separate libraries

[bugzilla-daemon at webkit.org]

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





--- Comment #4 from Halton Huo <halton.huo at gmail.com>  2012-12-21 00:07:40 PST ---
(In reply to comment #3)
> Basically, I don't wanna object to divide into small libraries. But, AFAIK, SHARED_CORE build option is to reduce linking time as well. Why not adjust this splitting into existing SHARED_CORE option ? BTW, could you share how much linking time we can reduce when using this dividing library ?

My intent for this bug is to resolving libwebcore_efl.a is too big(over 4g) to archive issue. Note, this is only for non shared_core build. For shared_core build, size of libwebcore_efl.so is okay (1.2g). Again, this is only for Debug build, Release build does not has this issue. Following table can make things more clear.

Debug(non-shared): libwebcore_efl.a over 4g
Debug(shared): libwebcore_efl.so 1.2g
Release(non-shared): libwebcore_efl.a 119m
Release(shared): libwebcore_efl.so 1.2g 47m

So split libwebcore_efl(shared or non-shared) won't speed up linking time.

But I do find some linking issues for debug non-shared build. My understanding only  libewebkit.so (or libewebkit2.so) should be linked to targets MiniBrowser, EWebLauncher, DumpRenderTree and WebKitTestRunner, test_ewk_*, test_ewk2_* and test_webkit2_api_*. The static libraries the wtf_efl.a, javascript_efl.a and libwebcore_efl.a are still listed in link.txt. That may cause the linking time too long.

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