Just added 'SHARED=1':
   http://code.google.com/p/chromium/wiki/ChromiumSoftwareConstructionSystem

On Dec 26, 6:24 am, Evan Martin <[email protected]> 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.
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: [email protected] 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to