Mozilla has this flexibility (for all platforms) and it's a very nice feature in their build system. I think ultimately we should aspire to do this on mac and windows too (hopefully when we're all unified on [insert newfangled build system here]).
On Sun, Dec 28, 2008 at 11:47 AM, skana...@gmail.com <skana...@gmail.com> wrote: > > Just added 'SHARED=1': > http://code.google.com/p/chromium/wiki/ChromiumSoftwareConstructionSystem > > On Dec 26, 6:24 am, Evan Martin <e...@chromium.org> wrote: >> 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. > > > -- Mike Pinkerton Mac Weenie pinker...@google.com --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
