I've checked in some changes that make it so you can build (on Linux) with shared libraries. This significantly reduces link times and overall build times at the cost of slower code and slower startup (i.e., you shouldn't use it for user-facing builds).
== Background Chromium has historically built as one huge shared object (.dll/.so), which means the linker can make more intelligent decisions (like eliminating dead code across modules) at the cost of making link times significantly slower. For example, a debug build of test_shell on linux is currently 400+ megabytes (!) and part of the way scons builds involves copying that file once upon successful linking (!!). A shared-library version of test_shell produces a 232kb executable along with 26 .so files. In theory, if you don't touch code within one of the chrome submodules, then its .so doesn't need to be relinked. == How to use it $ normal_hammer_command_line SHARED=1 Source files used in libraries should compile to ".os" rather than ".o" (they're different outputs -- e.g. position-independent code with -fPIC). If you have .so files in Hammer/dbg/lib/ , it appears to always produce shared executables regardless of your SHARED setting (?). I need to investigate further why. You can rm Hammer/dbg/lib/*.so to stop that for now. == Link time numbers Editing one test_shell file, rebuilding: 46s. Null build after that: 40s. This implies that the compile+link+copy time of test_shell was 6 seconds and the other 40 is scons-related overhead (including stat()ing a bunch of files, etc.). For comparison, linking test_shell statically takes 124s on my laptop, with 42 second null build time. So it saves about 78 seconds to dynamically link, or it's roughly 13 times faster. (Note that above numbers are with the slow standard binutils linker, rather than gold, and with my slow laptop, so your times may vary.) == Grungy details The scons build scripts do most of the work, including setting RPATH on the resulting binary, so you don't need to mess with LD_LIBRARY_PATH. We now use ChromeLibrary (rather than ChromeStaticLibrary) for all build commands, and should also use it in the future. Stuff that always needs to be shared (i.e. plugins) can continue using ChromeSharedLibrary. == Fixing modules that are missing symbols when built shared The dynamic linker refuses to build shared libraries that are missing symbols. It turns out in our code since we have traditionally statically linked everything, we've been ok with missing symbols as long as those functions/data are never referenced. I had to make some changes to bring in or stub out missing bits of code; in a static build they should be eliminated by the linker as before. I expect the shared build to occasionally break in the future due to this difference. It might be worth making a builder for it, or just switching the Linux debug build to it. Another difference with shared code is dependency chains matter more. googleurl's unittest uses libbase, which officially depends on libevent despite the googleurl unittest not making use of libevent. So for a static build, it links fine, but for a dynamic build you'll get missing symbol errors when linking. The fix is to change anybody who uses libbase to pull in libevent as well (on platforms that use libevent). The proper way to do this is to modify using_base.scons to pull in libevent, and then change anyone who uses libbase to use using_base.scons instead of referring to base directly. Check out build/googleurl_unittests.scons and build/using_googleurl.scons for an example. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
