[chromium-dev] Re: Scalability
Hi The patch below should fix it (there are arguably other perhaps better ways to tackle the debugger dependency etc.). With that patch, the linux shared make build compiles and links all targets for me. --Craig diff --git a/chrome/chrome.gyp b/chrome/chrome.gyp index 3fa1905..c0caeb6 100755 --- a/chrome/chrome.gyp +++ b/chrome/chrome.gyp @@ -741,6 +741,7 @@ 'common', 'chrome_resources', 'chrome_strings', +'debugger', 'theme_resources', '../app/app.gyp:app_resources', '../app/app.gyp:app_strings', @@ -3024,6 +3025,7 @@ '../third_party/npapi/npapi.gyp:npapi', '../webkit/webkit.gyp:glue', '../native_client/src/trusted/plugin/plugin_chrome.gyp:npGoogleNaClPluginChrome', + '../native_client/src/trusted/service_runtime/service_runtime.gyp:expiration', '../native_client/src/trusted/service_runtime/service_runtime.gyp:sel', '../native_client/src/trusted/validator_x86/validator_x86.gyp:ncvalidate', '../native_client/src/trusted/platform_qualify/platform_qualify.gyp:platform_qual_lib', On Tue, Oct 13, 2009 at 3:35 AM, Jacob Mandelson ja...@mandelson.org wrote: On Mon, Oct 12, 2009 at 06:29:02PM -0700, Lei Zhang wrote: Maybe you need to clobber? The shared build bot on the FYI waterfall is working: http://build.chromium.org/buildbot/waterfall.fyi/builders/Chromium%20Linux%20Builder%20(dbg-shlib)/builds/1069 gclient runhooks regenerated a bunch of .mk's, but I'm still getting the same link error. -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Wed, Oct 07, 2009 at 06:48:15PM +0200, Craig Schlenter wrote: On Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter craig.schlen...@gmail.com wrote: [big snip] This problem only seems to happen with the scons shared build. The make build does not have this problem so there seems to be something different about how the dependencies are being generated with the make versus scons gyp backends. I'm now getting build failures for linux_page_load_uitest with the shared object build, under both scons and make: /mnt/sda4/chromium/src/out/Debug/obj/chrome/libbrowser.so: undefined reference to `DevToolsManager::ActivateWindow(RenderViewHost*)' ... and a bunch of other DevToolsManager:: undefined references. (32-bit, Debug. Giving 32-bit Release a spin now.) -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
Maybe you need to clobber? The shared build bot on the FYI waterfall is working: http://build.chromium.org/buildbot/waterfall.fyi/builders/Chromium%20Linux%20Builder%20(dbg-shlib)/builds/1069 On Mon, Oct 12, 2009 at 6:23 PM, Jacob Mandelson ja...@mandelson.org wrote: On Wed, Oct 07, 2009 at 06:48:15PM +0200, Craig Schlenter wrote: On Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter craig.schlen...@gmail.com wrote: [big snip] This problem only seems to happen with the scons shared build. The make build does not have this problem so there seems to be something different about how the dependencies are being generated with the make versus scons gyp backends. I'm now getting build failures for linux_page_load_uitest with the shared object build, under both scons and make: /mnt/sda4/chromium/src/out/Debug/obj/chrome/libbrowser.so: undefined reference to `DevToolsManager::ActivateWindow(RenderViewHost*)' ... and a bunch of other DevToolsManager:: undefined references. (32-bit, Debug. Giving 32-bit Release a spin now.) -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Mon, Oct 12, 2009 at 06:29:02PM -0700, Lei Zhang wrote: Maybe you need to clobber? The shared build bot on the FYI waterfall is working: http://build.chromium.org/buildbot/waterfall.fyi/builders/Chromium%20Linux%20Builder%20(dbg-shlib)/builds/1069 gclient runhooks regenerated a bunch of .mk's, but I'm still getting the same link error. -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter
craig.schlen...@gmail.com wrote:
On Tue, Oct 6, 2009 at 11:09 PM, Jacob Mandelson ja...@mandelson.org wrote:
On Tue, Oct 06, 2009 at 09:19:49PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 8:14 PM, Craig Schlenter
craig.schlen...@gmail.com wrote:
On Tue, Oct 6, 2009 at 7:51 PM, Jacob Mandelson ja...@mandelson.org
wrote:
On Tue, Oct 06, 2009 at 07:39:14PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin e...@chromium.org wrote:
On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson ja...@mandelson.org
wrote:
I tried this, and it does indeed link far, far faster!
However, I got errors about RegisterInternalNaClPlugin():
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int,
int*))'
(Also one for libbrowser.so)
In general, the shared link breaks frequently. Whenever I work from a
cafe or wherever from my laptop, I usually will do a TBR commit or two
to fix the shared link.
The shared build is working perfectly for me FWIW but that is on 32 bit.
Are you on 64 bit or do you have any special gyp variables etc. set?
I'm on 32-bit. Only gyp changes from stock I have are:
{'variables': {
'library': 'shared_library',
'remove_webcore_debug_symbols': 1,
}}
Ah, you're doing a debug build then? I have only tested release recently.
I'll poke at a debug build tomorrow and try to sort it out ...
Hm ... debug build is also fine for me and I'm building with the
same gyp variables as you (except that I also have gcc_version=44).
If you stick your build into verbose mode can you see if it is linking
librenderer.so with libnpGoogleNaClPluginChrome.a? Maybe clobbering,
regyping etc. will encourage it to do that.
PS. I'm on r28124
I switched to --mode=Release, got strict-aliasing warnings^Werrors, stuck
on -Wno-strict-aliasing, and it landed back in
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))'
Running gclient runhooks had no effect here.
Building with --verbose shows the very long link line attached, which
has [nN][aA][cC][lL] only in -lnacl.
This problem only seems to happen with the scons shared build. The
make build does not have this problem so there seems to be something
different about how the dependencies are being generated with the make
versus scons gyp backends.
So the executive summary of the current situation is this:
1. Both libbrowser.so and librenderer.so call RegisterInternalNaClPlugin
2. RegisterInternalNaClPlugin lives in libnpGoogleNaClPluginChrome.a
3. libnpGoogleNaClPluginChrome.a is listed as a dependency of
libnacl.so (but it doesn't actually seem to be)
4. librenderer depends on nacl but nacl doesn't export its own
dependency on libnpGoogleNaClPluginChrome either
5. libbrowser doesn't depend on nacl which doesn't really help either.
In order to fix this, we really want to say that anything that
actually uses 'RegisterInternalNaClPlugin' should be linked against
libnpGoogleNaClPluginChrome.a. It is preferable to link the final
executable target with that rather than other intermediate
libraries like libbrowser and librenderer to avoid situations like
issue 5933.
One option (which works at least for the linux scons shared build
chrome target) is to remove
'../native_client/src/trusted/plugin/plugin_chrome.gyp:npGoogleNaClPluginChrome'
from the nacl dependencies and add it to the chrome dependencies in
chrome.gyp. It might also have to be specified manually for other
users of libbrowser and librenderer but that seems messy. I have only
tested this with the shared linux scons build btw.
Perhaps a gyp expert could suggest a better way?
Thanks!
PS. I haven't looked into why the make build gets this stuff right.
I'd guess it is over-specifying dependencies versus what is actually
declared in the gyp files?
--Craig
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Mon, Oct 05, 2009 at 10:20:47AM -0700, Steven Knight wrote: The variable name is actually just 'library'. The default is set in build/common.gypi. You can either change the default variable right in build/common.gypi or set the environment variable GYP_DEFINES=library=shared_library to get a shared library build. (I have it modified locally in one of my checked-out Linux trees for periodic sanity checks that Linux at least nominally builds with shared libraries. IIRC, a lot of the Linux folks use shared library builds regularly, for the much faster link times.) I tried this, and it does indeed link far, far faster! However, I got errors about RegisterInternalNaClPlugin(): /mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so: undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))' (Also one for libbrowser.so) I see these are protected by #ifndef DISABLE_NACL and if (command_line.HasSwitch(switches::kInternalNaCl)), but why would that affect things? DISABLE_NACL should be defined or not the same for shared or static build, and the HasSwitch is a run-time check. If I comment them out, then chrome links. But the call is in RenderProcess::RenderProcess(), surely not dead code that the static link would be removing. Any idea what's going on here? -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson ja...@mandelson.org wrote: I tried this, and it does indeed link far, far faster! However, I got errors about RegisterInternalNaClPlugin(): /mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so: undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))' (Also one for libbrowser.so) In general, the shared link breaks frequently. Whenever I work from a cafe or wherever from my laptop, I usually will do a TBR commit or two to fix the shared link. I see these are protected by #ifndef DISABLE_NACL and if (command_line.HasSwitch(switches::kInternalNaCl)), but why would that affect things? DISABLE_NACL should be defined or not the same for shared or static build, and the HasSwitch is a run-time check. If I comment them out, then chrome links. But the call is in RenderProcess::RenderProcess(), surely not dead code that the static link would be removing. Any idea what's going on here? Perhaps NACL isn't yet working in the shared build. I think NACL is on now, so DISABLE_NACL should be undefined. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Tue, Oct 06, 2009 at 07:39:14PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin e...@chromium.org wrote:
On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson ja...@mandelson.org wrote:
I tried this, and it does indeed link far, far faster!
However, I got errors about RegisterInternalNaClPlugin():
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))'
(Also one for libbrowser.so)
In general, the shared link breaks frequently. Whenever I work from a
cafe or wherever from my laptop, I usually will do a TBR commit or two
to fix the shared link.
The shared build is working perfectly for me FWIW but that is on 32 bit.
Are you on 64 bit or do you have any special gyp variables etc. set?
I'm on 32-bit. Only gyp changes from stock I have are:
{'variables': {
'library': 'shared_library',
'remove_webcore_debug_symbols': 1,
}}
-- Jacob
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Tue, Oct 6, 2009 at 8:14 PM, Craig Schlenter
craig.schlen...@gmail.com wrote:
On Tue, Oct 6, 2009 at 7:51 PM, Jacob Mandelson ja...@mandelson.org wrote:
On Tue, Oct 06, 2009 at 07:39:14PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin e...@chromium.org wrote:
On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson ja...@mandelson.org
wrote:
I tried this, and it does indeed link far, far faster!
However, I got errors about RegisterInternalNaClPlugin():
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))'
(Also one for libbrowser.so)
In general, the shared link breaks frequently. Whenever I work from a
cafe or wherever from my laptop, I usually will do a TBR commit or two
to fix the shared link.
The shared build is working perfectly for me FWIW but that is on 32 bit.
Are you on 64 bit or do you have any special gyp variables etc. set?
I'm on 32-bit. Only gyp changes from stock I have are:
{'variables': {
'library': 'shared_library',
'remove_webcore_debug_symbols': 1,
}}
Ah, you're doing a debug build then? I have only tested release recently.
I'll poke at a debug build tomorrow and try to sort it out ...
Hm ... debug build is also fine for me and I'm building with the
same gyp variables as you (except that I also have gcc_version=44).
If you stick your build into verbose mode can you see if it is linking
librenderer.so with libnpGoogleNaClPluginChrome.a? Maybe clobbering,
regyping etc. will encourage it to do that.
PS. I'm on r28124
--Craig
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
On Tue, Oct 06, 2009 at 09:19:49PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 8:14 PM, Craig Schlenter
craig.schlen...@gmail.com wrote:
On Tue, Oct 6, 2009 at 7:51 PM, Jacob Mandelson ja...@mandelson.org wrote:
On Tue, Oct 06, 2009 at 07:39:14PM +0200, Craig Schlenter wrote:
On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin e...@chromium.org wrote:
On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson ja...@mandelson.org
wrote:
I tried this, and it does indeed link far, far faster!
However, I got errors about RegisterInternalNaClPlugin():
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int,
int*))'
(Also one for libbrowser.so)
In general, the shared link breaks frequently. Whenever I work from a
cafe or wherever from my laptop, I usually will do a TBR commit or two
to fix the shared link.
The shared build is working perfectly for me FWIW but that is on 32 bit.
Are you on 64 bit or do you have any special gyp variables etc. set?
I'm on 32-bit. Only gyp changes from stock I have are:
{'variables': {
'library': 'shared_library',
'remove_webcore_debug_symbols': 1,
}}
Ah, you're doing a debug build then? I have only tested release recently.
I'll poke at a debug build tomorrow and try to sort it out ...
Hm ... debug build is also fine for me and I'm building with the
same gyp variables as you (except that I also have gcc_version=44).
If you stick your build into verbose mode can you see if it is linking
librenderer.so with libnpGoogleNaClPluginChrome.a? Maybe clobbering,
regyping etc. will encourage it to do that.
PS. I'm on r28124
I switched to --mode=Release, got strict-aliasing warnings^Werrors, stuck
on -Wno-strict-aliasing, and it landed back in
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib/librenderer.so:
undefined reference to `RegisterInternalNaClPlugin(bool (*)(int, int*))'
Running gclient runhooks had no effect here.
Building with --verbose shows the very long link line attached, which
has [nN][aA][cC][lL] only in -lnacl.
gclient revinfo begins with
src: http://src.chromium.org/svn/trunk/s...@28154;
(Simpler way to get this?)
-- Jacob
--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---
flock
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/linker.lock
g++ -o
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib/librenderer.so
-L/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib
-Wl,-rpath=/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/lib
-pthread -m32 -shared -pthread -m32
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/automation/dom_automation_controller.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/bindings_utils.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/event_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/extension_process_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/js_only_v8_extensions.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/extensions/renderer_extension_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/loadtimes_extension_bindings.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/media/audio_renderer_impl.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/net/render_dns_master.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/net/render_dns_queue.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/about_handler.os
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/chromium/src/sconsbuild/Release/obj/chrome/renderer/renderer/audio_message_filter.os
[chromium-dev] Re: Scalability
On Fri, Oct 2, 2009 at 8:26 AM, Marc-Antoine Ruel mar...@chromium.org wrote: is linking. To give you an idea, here's a truncated dir list: (...) 10,223,616 dump_cache.exe 10,309,632 fetch_client.exe 10,600,448 net_perftests.exe 12,406,784 sync_unit_tests.exe 14,966,784 net_unittests.exe 22,118,400 mini_installer.exe 55,029,760 tab_switching_test.exe Does anyone (not necessarily you :P) have building a web of .dlls in their plans? I've seen a number of patches from mmoss to get that working on Linux with the intent of using it on buildbots... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
Yes, Nicolas is working on making webkit.dll. It's painful to do; I know, I tried last year. :) On Mon, Oct 5, 2009 at 11:42 AM, Evan Martin e...@chromium.org wrote: On Fri, Oct 2, 2009 at 8:26 AM, Marc-Antoine Ruel mar...@chromium.org wrote: is linking. To give you an idea, here's a truncated dir list: (...) 10,223,616 dump_cache.exe 10,309,632 fetch_client.exe 10,600,448 net_perftests.exe 12,406,784 sync_unit_tests.exe 14,966,784 net_unittests.exe 22,118,400 mini_installer.exe 55,029,760 tab_switching_test.exe Does anyone (not necessarily you :P) have building a web of .dlls in their plans? I've seen a number of patches from mmoss to get that working on Linux with the intent of using it on buildbots... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
If anyone want to work on this, we've left some breadcrumbs behind by declaring libraries that could be built as either static or shared as a GYP variable named library_type. It expands to static_library by default, but the intention was to make it easy to switch to a shared library build by flipping it to shared_library. I'm sure there's a bunch of work to be done even with that switch flipped, but it might be a good start if anyone's interested. Mark Evan Martin wrote: On Fri, Oct 2, 2009 at 8:26 AM, Marc-Antoine Ruel mar...@chromium.org wrote: is linking. To give you an idea, here's a truncated dir list: (...) 10,223,616 dump_cache.exe 10,309,632 fetch_client.exe 10,600,448 net_perftests.exe 12,406,784 sync_unit_tests.exe 14,966,784 net_unittests.exe 22,118,400 mini_installer.exe 55,029,760 tab_switching_test.exe Does anyone (not necessarily you :P) have building a web of .dlls in their plans? I've seen a number of patches from mmoss to get that working on Linux with the intent of using it on buildbots... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Scalability
The variable name is actually just 'library'. The default is set in build/common.gypi. You can either change the default variable right in build/common.gypi or set the environment variable GYP_DEFINES=library=shared_library to get a shared library build. (I have it modified locally in one of my checked-out Linux trees for periodic sanity checks that Linux at least nominally builds with shared libraries. IIRC, a lot of the Linux folks use shared library builds regularly, for the much faster link times.) --SK On Mon, Oct 5, 2009 at 9:00 AM, Mark Mentovai m...@chromium.org wrote: If anyone want to work on this, we've left some breadcrumbs behind by declaring libraries that could be built as either static or shared as a GYP variable named library_type. It expands to static_library by default, but the intention was to make it easy to switch to a shared library build by flipping it to shared_library. I'm sure there's a bunch of work to be done even with that switch flipped, but it might be a good start if anyone's interested. Mark Evan Martin wrote: On Fri, Oct 2, 2009 at 8:26 AM, Marc-Antoine Ruel mar...@chromium.org wrote: is linking. To give you an idea, here's a truncated dir list: (...) 10,223,616 dump_cache.exe 10,309,632 fetch_client.exe 10,600,448 net_perftests.exe 12,406,784 sync_unit_tests.exe 14,966,784 net_unittests.exe 22,118,400 mini_installer.exe 55,029,760 tab_switching_test.exe Does anyone (not necessarily you :P) have building a web of .dlls in their plans? I've seen a number of patches from mmoss to get that working on Linux with the intent of using it on buildbots... --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
