[chromium-dev] Re: Scalability
On Tue, Oct 13, 2009 at 08:26:38AM +0200, Craig Schlenter wrote: > 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. Thanks, that patch works for me! I can vouch at its review. -- 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
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 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 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
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 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 >> 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 Wed, Oct 07, 2009 at 06:48:15PM +0200, Craig Schlenter wrote: > On Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter > 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 Wed, Oct 7, 2009 at 10:00 AM, Craig Schlenter
wrote:
> On Tue, Oct 6, 2009 at 11:09 PM, Jacob Mandelson 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
>>> wrote:
>>> > On Tue, Oct 6, 2009 at 7:51 PM, Jacob Mandelson
>>> > 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 wrote:
>>> >>> >
>>> >>> > On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson
>>> >>> > 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 Tue, Oct 6, 2009 at 11:09 PM, Jacob Mandelson 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
>> wrote:
>> > On Tue, Oct 6, 2009 at 7:51 PM, Jacob Mandelson
>> > 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 wrote:
>> >>> >
>> >>> > On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson
>> >>> > 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.
--Craig
> gclient revinfo begins with
> src: http://src.chromium.org/svn/trunk/s...@28154;
> (Simpler way to get this?)
--~--~-~--~~~---~--~~
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
> wrote:
> > On Tue, Oct 6, 2009 at 7:51 PM, Jacob Mandelson 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 wrote:
> >>> >
> >>> > On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson
> >>> > 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
/mnt/sda4/media/contrib/chrome2/home/chrome-svn/tarball/ch
[chromium-dev] Re: Scalability
On Tue, Oct 6, 2009 at 8:14 PM, Craig Schlenter
wrote:
> On Tue, Oct 6, 2009 at 7:51 PM, Jacob Mandelson 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 wrote:
>>> >
>>> > On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson
>>> > 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 6, 2009 at 7:51 PM, Jacob Mandelson 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 wrote:
>> >
>> > On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson
>> > 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 ...
--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 07:39:14PM +0200, Craig Schlenter wrote:
> On Tue, Oct 6, 2009 at 6:58 PM, Evan Martin wrote:
> >
> > On Tue, Oct 6, 2009 at 9:21 AM, Jacob Mandelson 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 9:21 AM, Jacob Mandelson 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 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
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 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 > 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 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 wrote: > On Fri, Oct 2, 2009 at 8:26 AM, Marc-Antoine Ruel 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
On Fri, Oct 2, 2009 at 8:26 AM, Marc-Antoine Ruel 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 -~--~~~~--~~--~--~---
