On Aug 23, 2010, at 2:38 AM, Eric Seidel wrote: > SVG gets such a bad wrap. :) Wouldn't breaking WebCore into smaller > libraries fix these linker problems longer-term? For example, > breaking out platform into a .a, or the JS bindings? I guess we'd > have to make them .dylib instead of .a if we wanted to actually make > the linker happier.
Making multiple .a files wouldn't really do anything - they are just archives of .o files and linking them into a shared library would still be just as expensive. Splitting into multiple .dylib/.so/.dll's would impose a runtime cost, which I think is not a good tradeoff for faster linking (and easier linking with less memory). A long time ago in the mysterious pre-history of WebKit, I had the WebCore build set up to build a separate relocatable object file per directory, and then link them all into a final dynamic library. This does partial linking, making the final linker step less expensive, though I don't know how much less memory it would use. The command-line tools know how to do this, but Xcode does not, so we lost this feature once we adopted Xcode. It made linking significantly faster with no runtime cost. I am not sure if it would still work today or if there is a similar approach on Windows. To be more specific, what I used is 'ld -r', which works with both the Mac OS X linker and GNU ld. I believe Visual Studio also has an incremental linking feature, but I don't know how it works or whether we are using it currently. Regards, Maciej > > On Mon, Aug 23, 2010 at 2:26 AM, Jeremy Orlow <jor...@chromium.org> wrote: >> The Kernel usually reserves 1/4 (but up to 3/4 on some OSes) of the address >> space for itself + you can get fragmentation. So the linker only can use >> part of the 4gb of ram in your machine. So switching to a 64 bit linker >> would probably fix the problem for now. Another option is to disable some >> parts of WebKit you don't need (like SVG). >> J >> >> On Mon, Aug 23, 2010 at 3:26 AM, Chris Hatko <cha...@gmail.com> wrote: >>> >>> Hi Nico, >>> >>> Yes, I've got 32 bit MSVS2005. I found that turning off /LTCG and /GL >>> optimization allowed me to get past this error. Do we now need more >>> than 4Gigs of RAM to compile webkit with release optimizations? >>> >>> Chris >>> >>> On Sun, Aug 22, 2010 at 4:09 PM, Nico Weber <tha...@chromium.org> wrote: >>>> Are you using a 32 bit linker? Maybe it's running out of address space. >>>> >>>> Nico >>>> >>>> On Sun, Aug 22, 2010 at 12:32 PM, Chris Hatko <cha...@gmail.com> wrote: >>>>> I'm running revision 65648 and building cairo-win32 release I'm >>>>> getting "Not >>>>> enough space" when linking WebKit project. I have 40Gig free space on >>>>> this drive and 4Gigs of ram. >>>>> >>>>> Linking... >>>>> 11>fatal error C1083: Cannot open compiler intermediate file: >>>>> 'C:\cygwin\home\HATKO\WebKit\WebKitBuild\lib\WebKitLib.lib': Not >>>>> enough space >>>>> 11>LINK : fatal error LNK1257: code generation failed >>>>> 11>Build log was saved at >>>>> >>>>> "file://C:\cygwin\home\HATKO\WebKit\WebKitBuild\obj\WebKit\Release_Cairo\BuildLog.htm" >>>>> 11>WebKit - 1 error(s), 1 warning(s). >>>>> >>>>> Any idea what I can try? >>>>> >>>>> Thanks, >>>>> >>>>> Chris >>>>> _______________________________________________ >>>>> webkit-dev mailing list >>>>> webkit-dev@lists.webkit.org >>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>>>> >>>> >>> _______________________________________________ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev