from:"Craig Schlenter"

Re: [chromium-dev] seeking c++ expertise for a tiny tricky bit of code

2010-01-13 Thread Craig Schlenter

On Wed, Jan 13, 2010 at 9:28 PM, Peter Kasting  wrote:
> On Wed, Jan 13, 2010 at 11:22 AM, Craig Schlenter
>  wrote:
>>
>> Other than the immediate gain of "hiding" crbug.com/28749,
>
> Which you have a patch (actually two, but one with r+) for, right?

True. I was tweaking the latest patch though and was still hoping to
get some feedback on it (thanks for the alignment comments btw.).

>> I think the biggest
>> benefit is that end users relying on 4.4 builds are likely to have a more
>> stable
>> experience in future since it is a safe default.
>
> I don't understand what you mean.  Whichever way we set the flag, we'll be
> compiling with it.  So that will be the "safe" thing for others to compile
> us with.  Throwing -fstrict-aliasing has the added advantage that it makes
> _both_ settings "safe".

It does however make the default compile "unsafe" for the case where
the compiler
doesn't throw a warning as is the case for issue 28749.

>> The other thing it buys us is a more relaxed timetable to solve the
>> aliasing
>> problems if it doesn't break the tree by default.
>
> Do we have other aliasing problems?  If so my opinion changes.

There are some aliasing issues still in play. Off the top of my head:

1. unit_tests has what might be an issue in stl_tree.h or a compiler issue
 (bug filed with gcc ppl) and it was already using
-fno-strict-aliasing to avoid this with gcc 4.4.
2. skia has an unresolved issue. Note the filing date:
http://code.google.com/p/skia/issues/detail?id=18
3. v8 has an aliasing issue in dtoa and somewhere else that I forget.
4. there are issues in third party code of course eg. icu, webkit etc.

--Craig
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] seeking c++ expertise for a tiny tricky bit of code

2010-01-13 Thread Craig Schlenter

On Wed, Jan 13, 2010 at 9:00 PM, Peter Kasting  wrote:
> On Wed, Jan 13, 2010 at 10:53 AM, Craig Schlenter
>  wrote:
>>
>> I'm one try-server run away from possibly turning -fno-strict-aliasing on
>> for
>> all linux/bsd gcc: http://codereview.chromium.org/519034
>>
>> From a "process" standpoint, given that there is some disagreement here
>> is someone going to come find me with a clue bat if I commit this?
>
> I don't think anyone will be rabid :)
> That said, my comment in my prior email stands: if we're basically capable
> of throwing -fstrict-aliasing for first-party code now, what do we gain by
> instead throwing -fno-strict-aliasing?  I would be sad to see us do this
> unless it really buys us something.

Other than the immediate gain of "hiding" crbug.com/28749, I think the biggest
benefit is that end users relying on 4.4 builds are likely to have a more stable
experience in future since it is a safe default. The PPA ubuntu builds
from fta are
already running with no_strict_aliasing=1 btw.

The other thing it buys us is a more relaxed timetable to solve the aliasing
problems if it doesn't break the tree by default.

Anyway, I think I'll commit this and then go hide somewhere :)

--Craig
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] seeking c++ expertise for a tiny tricky bit of code

2010-01-13 Thread Craig Schlenter

On Wed, Jan 13, 2010 at 8:34 PM, Antoine Labour  wrote:
>
> On Wed, Jan 13, 2010 at 10:06 AM, Stephen White 
> wrote:
>>
>> On Wed, Jan 13, 2010 at 12:19 PM, Dan Kegel  wrote:
>>>
>>> On Wed, Jan 13, 2010 at 9:12 AM, Stephen White 
>>> wrote:
>>> > 2)  Most of the supposed performance advantage of strict aliasing rules
>>> > is
>>> > probably taken care of by memory disambiguation in modern (ie., Core2
>>> > and
>>> > later) CPUs.
>>>
>>> I kind of doubt that.  Disallowing aliasing lets the compiler do
>>> a number of high-level optimizations that the chip could never do on its
>>> own.
>>> See e.g.
>>>
>>> http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html
>>
>> (As a side note, I find this example somewhat contrived:  if this were
>> performance-critical code, the programmer would pull the dereference out of
>> the loop anyway, not rely on the compiler to do it.)
>> That said, the "data-driven" answer would be to run perf benchmarks with
>> and without strict aliasing, and see the effect.  It might even help us find
>> some hotspots which we could improve under MSVC.
>>>
>>> I'm for -fstrict-aliasing except for third_party.
>>
>> Whichever is decided, I think making it explicit would make life easier
>> for the people on different compiler versions.
>> Stephen
>
> I have a bias towards -fstrict-aliasing, but whichever the choice, I think
> we should have the same default for all the compiler versions (i.e. forcing
> it either way).
> For Chrome OS, we will use gcc 4.4 so we'll get more exposure in-house to
> that particular compiler.

I'm one try-server run away from possibly turning -fno-strict-aliasing on for
all linux/bsd gcc: http://codereview.chromium.org/519034

>From a "process" standpoint, given that there is some disagreement here
is someone going to come find me with a clue bat if I commit this?

Get your votes in now! :)

--Craig
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] seeking c++ expertise for a tiny tricky bit of code

2010-01-13 Thread Craig Schlenter

On Wed, Jan 13, 2010 at 7:42 PM, Evan Martin  wrote:
[snip]
> With that in mind I think we should explicitly use
> -fno-strict-aliasing until someone is willing to take the time to run
> buildbots, track down regressions, etc. for the other configuration.

I have a patch to do this :)

http://codereview.chromium.org/519034/show

It's easy to override locally and I'm happy to track stuff down and feed fixes
into the tree for aliasing issues until there is some test
infrastructure that tests
4.4 binaries to a reasonable degree where we'd be comfortable switching
back.

--Craig
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] seeking c++ expertise for a tiny tricky bit of code

2010-01-12 Thread Craig Schlenter

On Wed, Jan 13, 2010 at 8:07 AM, Antoine Labour  wrote:
>
> On Tue, Jan 12, 2010 at 10:15 AM, Craig Schlenter
>  wrote:
>>
>> On Tue, Jan 12, 2010 at 7:13 PM, Evan Martin  wrote:
>> > In this bug
>> >  http://code.google.com/p/chromium/issues/detail?id=28749
>> > It seems we're running afoul of a more finicky compiler not liking
>> > some tricks we're playing with objects and memory in LazyInstance.
>> > (You can skip down to comment #30 or so to get to the meat of it --
>> > above that point we were still trying to figure out what was causing
>> > the crash.)
>> >
>> > I know enough to say that it sounds like the solution to the problem
>> > should involve placement new, but that is the extent of my C++ skill.
>> > If you are a wizard, could you take a look at the patch Craig posted
>> > on the bug (http://codereview.chromium.org/519045/show) and comment
>> > there?
>>
>> [see base/lazy_instance.{h,c}]
>>
>> One possible way of attacking the problem is to ignore the stuff I
>> posted and just figure out how to plumb the return value from the
>> placement new in New() through to Pointer() and use that return value
>> instead of instance in Pointer() but to do it without bloating up the
>> header file with lots more code. It's the reinterpret_cast in
>> Pointer() that we want to avoid.
>>
>> I actually have a patch that does the ugly thing I suggested in the
>> last comment in rietveld but my brain is coming unstuck trying to work
>> out how to do Darin's suggestion which is likely to be more elegant
>> than my attempts.
>>
>> Any help is welcome :)
>
> In theory chars are ok to alias with anything.
> It may be completely stupid but... technically, &buff_ is not strictly
> speaking a char*, so reinterpret_cast-ing it may confuse the compiler.
> &buff_[0] however is a char* - did we try this trivial change ?

That makes the compiler toss an aliasing error immediately:

cc1plus: warnings being treated as errors
base/rand_util_posix.cc: In function ‘uint64 base::RandUint64()’:
base/rand_util_posix.cc:32: error: dereferencing pointer ‘instance’
does break strict-aliasing rules
base/rand_util_posix.cc:47: note: initialized from here

Beforehand the compiler didn't warn or error at all despite -Wall -Werror btw.
but it did detect the problem when I did -Wstrict-aliasing=2

I did fiddle with some char options after Dean suggested it but, AFAIK, casting
any Type * to a char * is allowed but the converse is not allowed (when it is
dereferenced) in terms of the aliasing rules.

> Also, from the header description: "It also preallocates the space for Type,
> as to avoid allocating the Type instance on the heap.  This may help with
> the performance of creating the instance, and reducing heap fragmentation.
>  This requires that Type be a complete type so we can determine the size."
> Have we measured it to be significant enough to make it worth banging our
> collective heads on this giant hack ?

JamesR also suggested just allocating something from the heap which would,
I agree, solve the problem but I was trying to keep LazyInstance as close as
possible to it's original form.

I have something that sort-of works btw. that still keeps the
lazyinstance helper
class around:

http://codereview.chromium.org/548011

Thank you,

--Craig
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] seeking c++ expertise for a tiny tricky bit of code

2010-01-12 Thread Craig Schlenter

On Tue, Jan 12, 2010 at 7:13 PM, Evan Martin  wrote:
> In this bug
>  http://code.google.com/p/chromium/issues/detail?id=28749
> It seems we're running afoul of a more finicky compiler not liking
> some tricks we're playing with objects and memory in LazyInstance.
> (You can skip down to comment #30 or so to get to the meat of it --
> above that point we were still trying to figure out what was causing
> the crash.)
>
> I know enough to say that it sounds like the solution to the problem
> should involve placement new, but that is the extent of my C++ skill.
> If you are a wizard, could you take a look at the patch Craig posted
> on the bug (http://codereview.chromium.org/519045/show) and comment
> there?

[see base/lazy_instance.{h,c}]

One possible way of attacking the problem is to ignore the stuff I
posted and just figure out how to plumb the return value from the
placement new in New() through to Pointer() and use that return value
instead of instance in Pointer() but to do it without bloating up the
header file with lots more code. It's the reinterpret_cast in
Pointer() that we want to avoid.

I actually have a patch that does the ugly thing I suggested in the
last comment in rietveld but my brain is coming unstuck trying to work
out how to do Darin's suggestion which is likely to be more elegant
than my attempts.

Any help is welcome :)

--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: buildbot failure in Chromium on Webkit (dbg)(1), revision 35699

2010-01-07 Thread Craig Schlenter

Random hang unrelated to my change AFAICS ... looks like it's going green on
the next build.

--Craig


On Thu, Jan 7, 2010 at 12:55 PM,  wrote:

>  http://build.chromium.org/buildbot/waterfall/
>
> Automatically closing tree for "test_shell_tests" on "Webkit (dbg)(1)"
>
>
> http://build.chromium.org/buildbot/waterfall/builders/Webkit%20%28dbg%29%281%29/builds/14333
>
> Revision: 35699
> Blame list: craig.schlen...@chromium.org
>
>  Webkit (dbg)(1)
> Build 
> 14333
> svnkill
> stdio
>   update
> scripts
> stdio
> taskkill
> stdio
> update
> stdio
>   extract
> build
> stdio
> test_shell_tests
> did not complete
> crashed or hung
> stdio
>
> Changed by: *craig.schlen...@chromium.org*
> Changed at: *Thu 07 Jan 2010 02:39:34*
> Branch: *src*
> Revision: 
> *35699*
> Changed files:
>
>- *chrome/common/extensions/update_manifest.cc*
>
> Comments:
>
> Add some missing va_end calls to match va_start.
>
> BUG=31085
>
> Review URL: http://codereview.chromium.org/525073
>
> Properties:
>
>
>
-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] "make all" doesn't work.

2009-12-03 Thread Craig Schlenter

Hi

One known problem with the make build is that you sometimes have to
run it twice to rebuild the chrome target as the strings sometimes
don't get rebuilt properly but if make chrome does something, then in
theory make/make all should have built that too.

What does make chrome build that make all doesn't? - that might give
us some clues as to what is wrong.

--Craig

On Fri, Dec 4, 2009 at 7:53 AM, James Su  wrote:
> Unfortunately, it doesn't work. Actually, "make" == "make all".
>
> - James Su
>
> 2009/12/4 Craig Schlenter 
>>
>> I think you don't need to specify a target to build everything i.e.
>> just type make and it should work.
>>
>> --Craig
>>
>> On Fri, Dec 4, 2009 at 7:44 AM, James Su  wrote:
>> > Hi,
>> >   I just switched to use make to build chromium linux, but I found that
>> > "make all" didn't work at all. It only told me: make: Nothing to be done
>> > for
>> > `all'. Though it works if I specify the target name explicitly, such as
>> > "make chrome". Is it a known issue of gyp? Or I missed something?
>> >
>> > - James Su
>> >
>> > --
>> > Chromium Developers mailing list: chromium-dev@googlegroups.com
>> > View archives, change email options, or unsubscribe:
>> > http://groups.google.com/group/chromium-dev
>
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] "make all" doesn't work.

2009-12-03 Thread Craig Schlenter

I think you don't need to specify a target to build everything i.e.
just type make and it should work.

--Craig

On Fri, Dec 4, 2009 at 7:44 AM, James Su  wrote:
> Hi,
>   I just switched to use make to build chromium linux, but I found that
> "make all" didn't work at all. It only told me: make: Nothing to be done for
> `all'. Though it works if I specify the target name explicitly, such as
> "make chrome". Is it a known issue of gyp? Or I missed something?
>
> - James Su
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Symbolized backtrace on Linux chromium?

2009-11-30 Thread Craig Schlenter

The bug that is triggering here might be 28526 btw. ... ukai has a
patch in review for that.

--Craig

On Mon, Nov 30, 2009 at 7:37 PM, Chris Bentzel  wrote:
> When DCHECK's trigger on my debug chromium build, I get an unsymbolized
> stacktrace like
> [7036:25234:31462940569:FATAL:net/ocsp/nss_ocsp.cc(251)] Check failed:
> !request_.
> [7036:25234:31462940569:FATAL:net/ocsp/nss_ocsp.cc(251)] Check failed:
> !request_.
> Backtrace:
> out/Debug/chrome [0x8d7d9bc]
> out/Debug/chrome [0x8d99838]
> out/Debug/chrome [0x8fba726]
> out/Debug/chrome [0x8fb7f7b]
> out/Debug/chrome [0x8fb7f8f]
> out/Debug/chrome [0x8fb90e1]
> out/Debug/chrome [0x8fb9444]
> /usr/lib/libnss3.so.1d [0xb7884ed4]
> /usr/lib/libnss3.so.1d [0xb788ed68]
> /usr/lib/libnss3.so.1d [0xb783533a]
> /usr/lib/libnss3.so.1d [0xb7836020]
> /usr/lib/libnss3.so.1d [0xb784e8dd]
> /usr/lib/libnss3.so.1d [0xb7852527]
> /usr/lib/libnss3.so.1d [0xb78535a7]
> /usr/lib/libnss3.so.1d [0xb7858548]
> /usr/lib/libnss3.so.1d [0xb785a5b6]
> /usr/lib/libnss3.so.1d(CERT_PKIXVerifyCert+0x464) [0xb77d7ce4]
> out/Debug/chrome [0x90ee205]
> out/Debug/chrome [0x90eeed7]
> out/Debug/chrome [0x90b3ed5]
> out/Debug/chrome [0x90b399e]
> out/Debug/chrome [0x90b39d9]
> out/Debug/chrome [0xa00ec3c]
> out/Debug/chrome [0x8dafe2e]
> /lib/tls/i686/cmov/libpthread.so.0 [0xb77044fb]
> /lib/tls/i686/cmov/libc.so.6(clone+0x5e) [0xb73a2e5e]
> It looks like this was built with the -g option, and file out/Debug/chrome
> shows that it's not stripped. This was built from head this morning.
> Is there a reason I'm not getting symbols to display here?
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-dev

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Warning message when running chrome in gdb

2009-11-29 Thread Craig Schlenter

Given that the error message suggests that it is an internal error in
gdb, that seems somewhat unlikely IMHO. You could swap back to gnu-ld
of course if you have enough RAM to link and see what happens ...

--Craig

On Sun, Nov 29, 2009 at 1:50 AM, n179911  wrote:
> Thanks. I am using the gold linker on ubuntu 9.10. I wonder if that causes
> the problem.
>
> On Sat, Nov 28, 2009 at 1:33 PM, Dan Kegel  wrote:
>>
>> Might not hurt to build from the latest sources and make sure they haven't
>> fixed
>> it already, too.
>>
>> On Sat, Nov 28, 2009 at 5:57 AM, Craig Schlenter
>>  wrote:
>> > You could file a bug with the gdb people ... keeping a copy of the
>> > problematic binary/associated libraries may help them track it down.
>> >
>> > http://sourceware.org/bugzilla/
>> >
>> > --Craig
>> >
>> > On Sat, Nov 28, 2009 at 10:31 AM, n179911  wrote:
>> >> Thanks. I am building and debugging chromium on ubuntu 9.10, which
>> >> already
>> >> has the latest gdb, which is 7.0 version.
>> >>
>> >> On Fri, Nov 27, 2009 at 10:18 PM, Craig Schlenter
>> >>  wrote:
>> >>>
>> >>> I have a vague recollection of having seen this before ... upgrading
>> >>> gdb may help.
>> >>>
>> >>> http://sourceware.org/ml/gdb-patches/2003-01/msg00074.html
>> >>>
>> >>> --Craig
>> >>>
>> >>> On Sat, Nov 28, 2009 at 8:06 AM, Evan Martin 
>> >>> wrote:
>> >>> > I have never encountered this.  Have you tried searching for the
>> >>> > error
>> >>> > message?
>> >>> >
>> >>> > On Fri, Nov 27, 2009 at 4:31 PM, n179911  wrote:
>> >>> >> Hi,
>> >>> >> I am trying to run chrome under ubuntu. But I see a lot of
>> >>> >> 'internal
>> >>> >> error
>> >>> >> in the warning message'.  Can you please tell me what does those
>> >>> >> means
>> >>> >> and
>> >>> >> how can I fix those?
>> >>> >> Thank you.
>> >>> >> $ gdb out/Debug/chrome
>> >>> >>
>> >>> >> warning: (Internal error: pc 0xed21a0 in read in psymtab, but not
>> >>> >> in
>> >>> >> symtab.)
>> >>> >> warning: (Internal error: pc 0xed21a1 in read in psymtab, but not
>> >>> >> in
>> >>> >> symtab.)
>> >>> >> warning: (Internal error: pc 0xed21a0 in read in psymtab, but not
>> >>> >> in
>> >>> >> symtab.)
>> >>> >> warning: (Internal error: pc 0xed21a1 in read in psymtab, but not
>> >>> >> in
>> >>> >> symtab.)
>> >>> >> warning: (Internal error: pc 0xed21a0 in read in psymtab, but not
>> >>> >> in
>> >>> >> symtab.)
>> >>> >> warning: (Internal error: pc 0xed21a1 in read in psymtab, but not
>> >>> >> in
>> >>> >> symtab.)
>> >>> >>
>> >>> >> --
>> >>> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> >>> >> View archives, change email options, or unsubscribe:
>> >>> >> http://groups.google.com/group/chromium-dev
>> >>> >
>> >>> > --
>> >>> > Chromium Developers mailing list: chromium-dev@googlegroups.com
>> >>> > View archives, change email options, or unsubscribe:
>> >>> >    http://groups.google.com/group/chromium-dev
>> >>
>> >>
>> >
>> > --
>> > Chromium Developers mailing list: chromium-dev@googlegroups.com
>> > View archives, change email options, or unsubscribe:
>> >    http://groups.google.com/group/chromium-dev
>
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Warning message when running chrome in gdb

2009-11-28 Thread Craig Schlenter

You could file a bug with the gdb people ... keeping a copy of the
problematic binary/associated libraries may help them track it down.

http://sourceware.org/bugzilla/

--Craig

On Sat, Nov 28, 2009 at 10:31 AM, n179911  wrote:
> Thanks. I am building and debugging chromium on ubuntu 9.10, which already
> has the latest gdb, which is 7.0 version.
>
> On Fri, Nov 27, 2009 at 10:18 PM, Craig Schlenter
>  wrote:
>>
>> I have a vague recollection of having seen this before ... upgrading
>> gdb may help.
>>
>> http://sourceware.org/ml/gdb-patches/2003-01/msg00074.html
>>
>> --Craig
>>
>> On Sat, Nov 28, 2009 at 8:06 AM, Evan Martin  wrote:
>> > I have never encountered this.  Have you tried searching for the error
>> > message?
>> >
>> > On Fri, Nov 27, 2009 at 4:31 PM, n179911  wrote:
>> >> Hi,
>> >> I am trying to run chrome under ubuntu. But I see a lot of 'internal
>> >> error
>> >> in the warning message'.  Can you please tell me what does those means
>> >> and
>> >> how can I fix those?
>> >> Thank you.
>> >> $ gdb out/Debug/chrome
>> >>
>> >> warning: (Internal error: pc 0xed21a0 in read in psymtab, but not in
>> >> symtab.)
>> >> warning: (Internal error: pc 0xed21a1 in read in psymtab, but not in
>> >> symtab.)
>> >> warning: (Internal error: pc 0xed21a0 in read in psymtab, but not in
>> >> symtab.)
>> >> warning: (Internal error: pc 0xed21a1 in read in psymtab, but not in
>> >> symtab.)
>> >> warning: (Internal error: pc 0xed21a0 in read in psymtab, but not in
>> >> symtab.)
>> >> warning: (Internal error: pc 0xed21a1 in read in psymtab, but not in
>> >> symtab.)
>> >>
>> >> --
>> >> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> >> View archives, change email options, or unsubscribe:
>> >> http://groups.google.com/group/chromium-dev
>> >
>> > --
>> > Chromium Developers mailing list: chromium-dev@googlegroups.com
>> > View archives, change email options, or unsubscribe:
>> >    http://groups.google.com/group/chromium-dev
>
>

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Warning message when running chrome in gdb

2009-11-27 Thread Craig Schlenter

I have a vague recollection of having seen this before ... upgrading
gdb may help.

http://sourceware.org/ml/gdb-patches/2003-01/msg00074.html

--Craig

On Sat, Nov 28, 2009 at 8:06 AM, Evan Martin  wrote:
> I have never encountered this.  Have you tried searching for the error 
> message?
>
> On Fri, Nov 27, 2009 at 4:31 PM, n179911  wrote:
>> Hi,
>> I am trying to run chrome under ubuntu. But I see a lot of 'internal error
>> in the warning message'.  Can you please tell me what does those means and
>> how can I fix those?
>> Thank you.
>> $ gdb out/Debug/chrome
>>
>> warning: (Internal error: pc 0xed21a0 in read in psymtab, but not in
>> symtab.)
>> warning: (Internal error: pc 0xed21a1 in read in psymtab, but not in
>> symtab.)
>> warning: (Internal error: pc 0xed21a0 in read in psymtab, but not in
>> symtab.)
>> warning: (Internal error: pc 0xed21a1 in read in psymtab, but not in
>> symtab.)
>> warning: (Internal error: pc 0xed21a0 in read in psymtab, but not in
>> symtab.)
>> warning: (Internal error: pc 0xed21a1 in read in psymtab, but not in
>> symtab.)
>>
>> --
>> Chromium Developers mailing list: chromium-dev@googlegroups.com
>> View archives, change email options, or unsubscribe:
>> http://groups.google.com/group/chromium-dev
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev

-- 
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev

Re: [chromium-dev] Link error when compiling chromium on ubuntu 9.10

2009-11-23 Thread Craig Schlenter

On Mon, Nov 23, 2009 at 9:59 AM, hap 497  wrote:
> Hi,
>
> I am tying to compile chromium on ubuntu 9.10. I think the compilation
> went fine.
> I just get an error in linking.
> $ make -j5 chrome
>  LINK(target) out/Debug/chrome
> collect2: ld terminated with signal 9 [Killed]
> make: *** [out/Debug/chrome] Error 1
> $ make out/Debug/chrome
>  LINK(target) out/Debug/chrome
> collect2: ld terminated with signal 9 [Killed]
> make: *** [out/Debug/chrome] Error 1
>
> and i don't think i have a disk space problem since i check the df output:

You probably need more RAM or you should just use the gold linker (see
the wiki).

--Craig

> $ df
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /dev/sda1             14784680  10044024   3989620  72% /
> udev                    383892       216    383676   1% /dev
> none                    383892       360    383532   1% /dev/shm
> none                    383892        92    383800   1% /var/run
> none                    383892         0    383892   0% /var/lock
> none                    383892         0    383892   0% /lib/init/rw
>
> Thanks for any tip.
>
> --
> Chromium Developers mailing list: chromium-dev@googlegroups.com
> View archives, change email options, or unsubscribe:
>    http://groups.google.com/group/chromium-dev

-- 
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: Compiler warning with Arch Linux and make

2009-11-02 Thread Craig Schlenter


As Evan notes, things move quickly :)

What made the difference here is that Joel fixed that error and you
must have updated your tree.

--Craig

On Sun, Nov 1, 2009 at 5:01 PM, Alexander Teinum  wrote:
>
> Success.
>
> Adding 'remove_webcore_debug_symbols' to include.gypi probably solved
> my problem (although I did a debug build now). This is the first time
> that I have had success compiling Chromium in Arch Linux with make.
> And it's also the first time that I have gotten a debug build working
> in Arch Linux.
>
> I don't know if it makes any difference, but I built with V=1.
>
> On Sat, Oct 31, 2009 at 3:55 PM, Alexander Teinum  wrote:
>> I'm trying to compile Chromium on 64-bit Arch Linux.
>>
>> It did work fine with SCons in release mode, but it seems like make is
>> going to replace SCons from what I have read in the recent
>> discussions. I have had a lot of pain compiling Chromium in general,
>> because of gperf, generated code, strict aliasing etc. I have still
>> not found a solution to those problems. But it did compile with SCons
>> when mode was set to release.
>>
>> I have created ~/.gyp/include.gypi, pasted in the settings from the
>> wiki, and set these variables:
>>
>> export GYP_GENERATORS=make
>> export GYP_DEFINES=target_arch=x64
>>
>> And finally:
>>
>> gclient sync
>> make chrome BUILDTYPE=Release
>>
>> Here's what happens with any recent, green build:
>>
>>  CXX(target) 
>> out/Release/obj.target/renderer/chrome/renderer/localized_error.o
>>  CXX(target) 
>> out/Release/obj.target/renderer/chrome/renderer/notification_provider.o
>>  CXX(target) 
>> out/Release/obj.target/renderer/chrome/renderer/print_web_view_helper.o
>>  CXX(target) 
>> out/Release/obj.target/renderer/chrome/renderer/print_web_view_helper_linux.o
>>  CXX(target) out/Release/obj.target/renderer/chrome/renderer/render_process.o
>>  CXX(target) out/Release/obj.target/renderer/chrome/renderer/render_thread.o
>> cc1plus: warnings being treated as errors
>> In file included from ./chrome/renderer/renderer_webkitclient_impl.h:9,
>>                 from chrome/renderer/render_thread.cc:45:
>> ./chrome/renderer/websharedworkerrepository_impl.h:10: error:
>> declaration ‘struct WebKit::WebSharedWorker’ does not declare anything
>> make: *** [out/Release/obj.target/renderer/chrome/renderer/render_thread.o]
>> Error 1
>>
>> Can anyone point me in the right direction?
>>
>> --
>> Best regards,
>>
>> Alexander Teinum
>>
>
>
>
> --
> Best regards/Med vennlig hilsen,
>
> Alexander Teinum
>
> >
>

--~--~-~--~~~---~--~~
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

2009-10-12 Thread Craig Schlenter


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

2009-10-07 Thread Craig Schlenter

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

2009-10-07 Thread Craig Schlenter


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

2009-10-06 Thread Craig Schlenter


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

2009-10-06 Thread Craig Schlenter


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: Unkown Error During Building Chromium for Linux

2009-10-06 Thread Craig Schlenter


Hi

I'm not seeing anything really revealing here ... maybe you are
running out of ram while linking?

dmesg may tell you if the "out-of-memory" kernel facility killed the ld process.

Also try investigating how to get the scons build to only run one job
at a time (for the make build it's -j 1 but I haven't touched scons
for ages). That will
(a) use less RAM and
(b) all the output messages will be useful rather than interleaved
with other irrelevant stuff.

--Craig

2009/10/6 Ujjwol (उज्जवल लामिछाने) :
>
> Ok the new build log with stderr logged
>
> ---
>  [?1034hscons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> Extracting last change to /home/Ujjwol/chromium/home/chrome-svn/
> tarball/chromium/src/sconsbuild/Debug/obj/_global_intermediate/build/
> LASTCHANGE
> Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/
> test/npapi_constants.os
> Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/
> test/npapi_test.os
> Linking /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/page_cycler_tests
> Linking /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/chrome
> Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/
> test/plugin_arguments_test.os
> Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/
> test/plugin_client.os
> Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/
> test/plugin_delete_plugin_in_stream_test.os
> Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/
> test/plugin_get_javascript_url_test.os
> Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/
> test/plugin_geturl_test.os
> Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/
> test/plugin_javascript_open_popup.os
> Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/
> test/plugin_new_fails_test.os
> Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/
> test/plugin_npobject_proxy_test.os
> Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/
> test/plugin_private_test.os
> Compiling /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/obj/test_shell/npapi_test_plugin/__/__/glue/plugins/
> test/plugin_test.os
> Building loadable module /home/Ujjwol/chromium/home/chrome-svn/tarball/
> chromium/src/sconsbuild/Debug/libnpapi_test_plugin.so
> collect2: ld returned 1 exit status
> scons: *** [/home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/page_cycler_tests] Error 1
> collect2: ld returned 1 exit status
> scons: *** [/home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
> sconsbuild/Debug/chrome] Error 1
> scons: building terminated because of errors.
> -
>
> On Oct 6, 12:17 pm, Lei Zhang  wrote:
>> It looks as though you didn't save stderr, only stdout, so the logs do
>> not contain any actual error messages.
>>
>> 2009/10/5 Ujjwol (उज्जवल लामिछाने) :
>>
>>
>>
>>
>>
>> > While building chromium in Fedora 10, a strange build error has been
>> > encountered.
>>
>> > The tail of the log of build(hammer --verbose) process is:
>>
>> > 
>> > [ujj...@ujjwol Desktop]$ tail VerboseChromeBuild.txt
>> > Copying /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
>> > sconsbuild/Debug/obj/chrome/_chrome_intermediate/repack/zh-CN.pak to /
>> > home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/sconsbuild/
>> > Debug/locales/zh-CN.pak ...
>> > Copying /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
>> > sconsbuild/Debug/obj/chrome/_chrome_intermediate/repack/zh-TW.pak to /
>> > home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/sconsbuild/
>> > Debug/locales/zh-TW.pak ...
>> > Copying /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
>> > sconsbuild/Debug/obj/chrome/_chrome_intermediate/repack/default.pak
>> > to /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
>> > sconsbuild/Debug/themes/default.pak ...
>> > g++ -o /home/Ujjwol/chromium/home/chrome-svn/tarball/chromium/src/
>> > sconsbuil

[chromium-dev] Re: [linux] user feedback one month in

2009-09-20 Thread Craig Schlenter


Hi

Does it work when you reload or do you have to clear the cache to make  
it happy? If you have to clear the cache then it might be 
http://crbug.com/22125 
  ...

--Craig

On 21 Sep 2009, at 4:52, "Elliot Glaysher (Chromium)"  
 wrote:

>
> On Sun, Sep 20, 2009 at 7:43 PM, Evan Martin   
> wrote:
>> - CSS occasionally lost while browsing
>> My response: I think I've seen this too, but I had been assuming it's
>> site glitches.  Does this ring any bells for anyone?
>
> I see this at least twice a day on my home connection. A site will
> load except for the corresponding CSS. There doesn't appear to be a
> pattern to it.
>
> -- Elliot
>
> >

--~--~-~--~~~---~--~~
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: Where does -Werror get disabled for WebCore?

2009-09-13 Thread Craig Schlenter


On Sun, Sep 13, 2009 at 9:31 PM, Mark Mentovai  wrote:
[snip]
> This is exactly the rationale for building code that's not our own
> with -Wall but not -Werror.
[snip]

Currently we remove -Wall in third party code though.

Do you want to turn it back on?

http://codereview.chromium.org/201105

--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: Where does -Werror get disabled for WebCore?

2009-09-13 Thread Craig Schlenter


Hi Ben

I think it's because webcore is not chromium_code.

See build/external_code.gypi for where -Werror and -Wall are removed.

--Craig

On Sun, Sep 13, 2009 at 7:10 PM, Ben Laurie  wrote:
>
> By default, cflags includes -Werror ... (see build/common.gypi).
>
> It seems something disables this for WebCore (which is built by
> webkit/webkit.gyp:webcore) but I can't figure out what - does anyone
> know?
>
> >
>

--~--~-~--~~~---~--~~
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: Improving power usage

2009-07-14 Thread Craig Schlenter

On Tue, Jul 14, 2009 at 3:09 PM, Joel Stanley wrote:
> On Tue, Jul 14, 2009 at 03:09, Craig Schlenter 
> wrote:
>> I've mentioned this to Joel off-list but in case anyone else is interested,
>> I have code that runs background tabs at lower scheduling priorities
>> on linux.
>
> Thanks.  Are you able to post the newer version you mentioned?

Attached. Haven't checked if it works with the latest tree.

>> Tweaks to /etc/security/limits.conf are necessary to make it work though
>> (to grant priority raising abilities).
>
> If we're just tweaking the priority level between 0 and 20 a normal
> user will have no worries.  It's only when we try to take it below 0
> that more capabilities are needed.
>
> $ renice +1 31404
> 31404: old priority 0, new priority 1
>
> $ renice -1 31404
> renice: 31404: setpriority: Permission denied
>
> $ renice +3 31404
> 31404: old priority 1, new priority 3
>
> $ renice +1 31404
> 31404: old priority 3, new priority 1
>
> OTOH, renicing isn't really going to help my quest to end unnecessary
> background work, it's just going to make sure the foreground gets more
> CPU share.

I was under the impression that lowering the priority was always allowed but
taking it back to the original level was denied. Can you get it back
to the original
priority 0 without the fiddling in /etc/security/limits.conf I
mentioned? Maybe your
distribution already grants you extra scheduling permissions? I'm on fedora 9.
ulimit -a may yield some clues ...

I concur that it will probably only help foreground processes get more
share of the
cpu but perhaps in conjunction with something like cpu clock
throttling, it might
help the machine use less power and still have a usable browsing experience in
the foreground tab. I haven't really studied any of the linux cpufreq
stuff yet though...

I'm not sure how often the browser pokes at the background tabs/renderers to see
if they are active but maybe you could alter that code to wake up the renderer,
wait a short while for the ping response and then stop the renderer again?

--Craig

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

commit-5bf3a45
Description: Binary data

[chromium-dev] Re: Improving power usage

2009-07-13 Thread Craig Schlenter

On Mon, Jul 13, 2009 at 6:22 PM, Evan Martin wrote:
[snip]
> One piece to look at is the code that calls SetProcessBackgrounded(),
> which on Windows marks the process as one that can be paged out but on
> Linux is not implemented.  I don't know how it decides it's ok to do
> that, but it'd be good logic to examine.

I've mentioned this to Joel off-list but in case anyone else is interested,
I have code that runs background tabs at lower scheduling priorities
on linux.

Tweaks to /etc/security/limits.conf are necessary to make it work though
(to grant priority raising abilities).

--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: Compile base_unittests fails

2009-07-12 Thread Craig Schlenter


Hi

If your compiler is that old btw, then it may help to poke at the list
below and see what else you need to update:
http://code.google.com/p/chromium/wiki/LinuxBuildInstructionsPrerequisites

Hopefully all those warnings will go away with something a bit more modern ...

--Craig

On Mon, Jul 13, 2009 at 7:43 AM, lawrence sue wrote:
>
> Thanks, my gcc version is out. I need update it.
> chrome[24-18:18:59]/home/chrome/src/base>gcc --version
> gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There
> is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
>
> On Jul 13, 1:18 pm, Evan Martin  wrote:
>> On Sun, Jul 12, 2009 at 8:38 PM, empriser wrote:
>> > third_party/dmg_fp/dtoa.cc: In function 'void dmg_fp::hexnan
>> > (dmg_fp::U*, const char**)':
>> > third_party/dmg_fp/dtoa.cc:1558: warning: array subscript has type
>> > 'char'
>>
>> The line in question is:
>>   if (!hexdig['0'])
>> So yes, the warning is correct.  What compiler are you using?  I am
>> curious why this hasn't affected us already.
>>
>> It looks like we've already patched around some warnings in this code,
>> so maybe we need to do more of 
>> that.http://src.chromium.org/viewvc/chrome/trunk/src/base/third_party/dmg_...
>>
>> (BTW, I also looked into whether our copy of this file is old, but we
>> match the newest version linked from the author's home page.)
> 

--~--~-~--~~~---~--~~
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: Compile base_unittests fails

2009-07-12 Thread Craig Schlenter


On Mon, Jul 13, 2009 at 8:34 AM, Craig
Schlenter wrote:
> Hi
>
> I thought none of the hex stuff was supposed be compiled. Line 183 does
> #define NO_HEX_FP
> but there is some interesting interaction between INFNAN_CHECK,
> No_Hex_NaN and Need_Hexdig which might result in it compiling
> for you. Hmmm 
>
> Try adding
> #define No_Hex_Nan


Whoops, wrong case .. that should be
#define No_Hex_NaN

--Craig

> after
> #define NO_HEX_FP
> perhaps?
>
> --Craig
>
> On Mon, Jul 13, 2009 at 7:18 AM, Evan Martin wrote:
>>
>> On Sun, Jul 12, 2009 at 8:38 PM, empriser wrote:
>>> third_party/dmg_fp/dtoa.cc: In function 'void dmg_fp::hexnan
>>> (dmg_fp::U*, const char**)':
>>> third_party/dmg_fp/dtoa.cc:1558: warning: array subscript has type
>>> 'char'
>>
>> The line in question is:
>>  if (!hexdig['0'])
>> So yes, the warning is correct.  What compiler are you using?  I am
>> curious why this hasn't affected us already.
>>
>> It looks like we've already patched around some warnings in this code,
>> so maybe we need to do more of that.
>> http://src.chromium.org/viewvc/chrome/trunk/src/base/third_party/dmg_fp/README.chromium
>>
>> (BTW, I also looked into whether our copy of this file is old, but we
>> match the newest version linked from the author's home page.)
>>
>> >

--~--~-~--~~~---~--~~
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: Compile base_unittests fails

2009-07-12 Thread Craig Schlenter


Hi

I thought none of the hex stuff was supposed be compiled. Line 183 does
#define NO_HEX_FP
but there is some interesting interaction between INFNAN_CHECK,
No_Hex_NaN and Need_Hexdig which might result in it compiling
for you. Hmmm 

Try adding
#define No_Hex_Nan
after
#define NO_HEX_FP
perhaps?

--Craig

On Mon, Jul 13, 2009 at 7:18 AM, Evan Martin wrote:
>
> On Sun, Jul 12, 2009 at 8:38 PM, empriser wrote:
>> third_party/dmg_fp/dtoa.cc: In function 'void dmg_fp::hexnan
>> (dmg_fp::U*, const char**)':
>> third_party/dmg_fp/dtoa.cc:1558: warning: array subscript has type
>> 'char'
>
> The line in question is:
>  if (!hexdig['0'])
> So yes, the warning is correct.  What compiler are you using?  I am
> curious why this hasn't affected us already.
>
> It looks like we've already patched around some warnings in this code,
> so maybe we need to do more of that.
> http://src.chromium.org/viewvc/chrome/trunk/src/base/third_party/dmg_fp/README.chromium
>
> (BTW, I also looked into whether our copy of this file is old, but we
> match the newest version linked from the author's home page.)
>
> 

--~--~-~--~~~---~--~~
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: Linux build totally busted.

2009-06-11 Thread Craig Schlenter

It might not be r18131 ... I compiled head without 18131 and even
though it looked like that helped earlier, it's broken again now.
Interestingly when opening new tabs, only some of them are broken
which is probably why I thought it was ok earlier ... will leave
something bisecting in the backround but it's a rather long cycle time
on my laptop to do each build.

--Craig

On Thu, Jun 11, 2009 at 12:42 PM, Craig
Schlenter wrote:
> Hi Dean
>
> I am seeing the same thing ... it seems to be r18131 that is at fault.
> I have not tracked it down further than that ...
>
> Shared build is also bust. See attached patch ... dunno if that's the right 
> fix.
>
> --Craig
>
> On Thu, Jun 11, 2009 at 11:58 AM, Dean McNamee wrote:
>> Something related to images, or resources, or decoders, or painting,
>> or something.  Multiple reports of everything being complete broken.
>>
>> Screenshot of my recent build attached.
>>
>> -- dean
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: Linux build totally busted.

2009-06-11 Thread Craig Schlenter

Hi Dean

I am seeing the same thing ... it seems to be r18131 that is at fault.
I have not tracked it down further than that ...

Shared build is also bust. See attached patch ... dunno if that's the right fix.

--Craig

On Thu, Jun 11, 2009 at 11:58 AM, Dean McNamee wrote:
> Something related to images, or resources, or decoders, or painting,
> or something.  Multiple reports of everything being complete broken.
>
> Screenshot of my recent build attached.
>
> -- dean
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---



shared.diff
Description: Binary data

[chromium-dev] compilation with gcc 4.4 - update

2009-05-28 Thread Craig Schlenter


Hi

Just a quick note that trunk should compile with gcc 4.4 in release
mode if you add the following tweak to ~/.gyp/include.gypi

{
  'variables': {
'gcc_version': '44',
   },
}

You should do a 'gclient runhooks --force' after tweaking this of course.

This is a temporary measure to turn on some extra compiler flags for
gcc 4.4 for v8. Lots of the code also has to have -fno-strict-aliasing
turned on under gcc 4.4 ... there is work underway (slowly) to resolve
some of these issues properly. Feel free to chime in at
http://code.google.com/p/chromium/issues/detail?id=9104 if you want to
help or drop me an email.

Remember that gcc 4.4 is not a recommended or widely used toolchain
for chromium so stuff may break from time to time and there may be
undiscovered compiler specific issues. YMMV.

--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: Cannot use "gcl change", svn fails. Any help is appreciated ...

2009-05-26 Thread Craig Schlenter


Hi

Are you using vaguely equivalent versions of svn btw. between windows
and linux? Sharing a working copy is always bad news for svn and I
suspect horrid issues between different versions of svn on windows and
linux or perhaps even cr/lf issues contributed to this problem :(

Given that you have the modified source files, you could paste those
into a fresh checkout and recreate/copy the gcl info stuff by hand if
you wanted to push updates to existing patches in rietveld. The
gcl_info stuff doesn't look too hard to fake and I have successfully
hand edited the files before to force it to update the right CL when I
screwed something up before.

I'd paste an example gcl_info changes file here but cut-and-paste
doesn't seem to be working in chrome in gmail now :(

--Craig

On Wed, May 27, 2009 at 8:09 AM, Mohamed Mansour
 wrote:
> Sorry for not being more "detailed in my problem", but I already tried
> moving the gcl_info cause its not part of svn. And the failure still
> persists. That is when I tried to msg dev mailing list.
>
> I don't want to loose my gcl_info patches, cause some patches of mine are
> already open, and if I download a new branch, I loose my CL's.
>
> -- Mohamed Mansour
>
>
> On Wed, May 27, 2009 at 2:04 AM, Evan Martin  wrote:
>>
>> You can debug it!
>>
>> From the backtrace you posted it looks like it's looking for a
>> directory under .svn called gcl_info or something, right?  I'd look to
>> see what's there, maybe try moving it to the side temporarily to see
>> if that helps, etc.
>>
>> On Tue, May 26, 2009 at 11:01 PM, Mohamed Mansour
>>  wrote:
>> >
>> > Sorry for another post, but now I am trying to commit my changes in
>> > Linux (It was working fine, I submitted a patch couple of days ago).
>> > Now I can't even do gcl changes command. What should I do to fix up my
>> > messups :( I have no experience in svn (only in chromium), so any help
>> > is appreciated.
>> >
>> > m...@m0-desktop:~/code/chromium/src$ gcl changes
>> > Traceback (most recent call last):
>> >  File "/mnt/backup/code/chromium/depot_tools/gcl.py", line 1149, in
>> > 
>> >    sys.exit(main())
>> >  File "/mnt/backup/code/chromium/depot_tools/gcl.py", line 1057, in
>> > main
>> >    if not os.path.exists(GetInfoDir()):
>> >  File "/mnt/backup/code/chromium/depot_tools/gcl.py", line 113, in
>> > GetInfoDir
>> >    return os.path.join(GetRepositoryRoot(), '.svn', 'gcl_info')
>> >  File "/mnt/backup/code/chromium/depot_tools/gcl.py", line 99, in
>> > GetRepositoryRoot
>> >    raise Exception("gcl run outside of repository")
>> > Exception: gcl run outside of repository
>> > m...@m0-desktop:~/code/chromium/src$
>> >
>> >
>> > On May 27, 1:53 am, Mohamed Mansour  wrote:
>> >> Hi,
>> >> Today I am trying to submit another patch, and it is not allowing me to
>> >> do
>> >> that, it somewhat fails. I am trying to do the following:
>> >>
>> >> gcl change 11435
>> >>
>> >> It brings up notepad and I add my stuff as I normally do. Then I save
>> >> and
>> >> close notepad. I run the gcl change command again (or even lint). I get
>> >> these svn issues.
>> >>
>> >> svn: Can't open file
>> >>
>> >> 'M:\code\chromium\src\chrome\browser\views\options\content_page_view.cc\.svn\entries':
>> >> The directory name is invalid.
>> >> svn: Can't open file
>> >>
>> >> 'M:\code\chromium\src\chrome\browser\views\options\advanced_contents_view.cc\.svn\entries':
>> >> The directory name is invalid.
>> >>
>> >> I run gcl change 11435 and I see those two files missing, so I do
>> >> another
>> >> lint, and I see.
>> >>
>> >> svn: Can't open file
>> >>
>> >> 'M:\code\chromium\src\chrome\browser\views\options\content_page_view.h\.svn\entries':
>> >> The directory name is invalid.
>> >>
>> >> I do another gcl change 11435 to see whats wrong, and my changed files
>> >> are
>> >> not in the list anymore, its like it deleted everything.
>> >>
>> >> What may have went wrong?
>> >>
>> >> Maybe my setup is incorrect, I am submitting bugs on linux and on
>> >> windows,
>> >> and I shared my ext3 linux partition in windows. I installed chromium
>> >> on
>> >> linux first, and today I decided to fix a bug, after spending 3 hours
>> >> on it
>> >> (refactoring etc) I can't submit the patch.
>> >>
>> >> I would really like to fix this. Any suggestions? Its 2 AM EST and IRC
>> >> seems
>> >> dead tonight after 10 :(.
>> >>
>> >> Thanks!
>> >>
>> >> -- Mohamed Mansour
>> > >
>> >
>
>
> >
>

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

Fwd: [chromium-dev] Re: cryptoht.h not found

2009-05-16 Thread Craig Schlenter


+chromium-dev

--Craig

-- Forwarded message --
From: Craig Schlenter 
Date: Sat, May 16, 2009 at 3:39 PM
Subject: Re: [chromium-dev] Re: cryptoht.h not found
To: Mohamed Mansour 


Hi Mohamed

The instructions at
http://dev.chromium.org/developers/how-tos/get-the-code say "6.
Updating your checkout once by running gclient sync --force in the
source code directory". Did you do that step?

I'm not clued up on the inner details of gclient but from a quick
glance at the source reveals the following helpful comment:

"Hooks
 .gclient and DEPS files may optionally contain a list named "hooks" to
 allow custom actions to be performed based on files that have changed in the
 working copy as a result of a "sync"/"update" or "revert" operation.  Hooks
 can also be run based on what files have been modified in the working copy
 with the "runhooks" operation.  If any of these operation are run with
 --force, all known hooks will run regardless of the state of the working
 copy."

That suggests that gclient sync --force should have run the hooks too
thus re-generating the scons files correctly.

It is a bit strange that there are existing scons files in the tarball
but I suspect that's a side-effect of how the tarballs are generated.
BUG 6385 suggests that Pam or Tony might be able to shed some light on
that but I'd guess that gyp is being run in the tree before the
tarball is generated thus producing scons files that are incompatible
with your environment.

--Craig

On Sat, May 16, 2009 at 9:13 AM, Mohamed Mansour
 wrote:
> Weird,
>
> I just received this error while compiling a "fresh" build on linux.
> Downloaded the tarball, and hammer (clean). The first error I saw on the
> screen was:
> cd: 1: can't cd to
> /auto/filer28.mtvvolmtvhome51/chrome-svn/tarball/chromium/src/base
>
> Then it stated:
> /home/m0/chromium/src/base/crypto/signature_verifier.h:11:22: error:
> cryptoht.h: No such file or directory
>
> I checked my pkg-config --cflags nss which returned:
> -I/usr/include/nss -I/usr/include/nspr
>
> I looked into it further and grep'd the gyp with mtvvolmtvhome51 and it
> appeared in couple. I had to do runhooks:
> gclient runhooks --force
>
> So my question, why does the tarball come with bad .scons files? Why doesn't
> the gclient sync regenerate them?
> Maybe add another step to the linux process that will tell the user to
> regenerate them after initial build. Many users having this problem it
> seems.
>
> -- Mohamed Mansour

--~--~-~--~~~---~--~~
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: gyp shared library builds on Linux

2009-04-24 Thread Craig Schlenter


Actually all the targets work ... Steven fixed them all and I just  
hadn't realised that so the hammer app thing and my earlier rambling  
is ignorable. I see from your other mail that you are using the  
tarball though so I'd recommend trying to sync up with the current svn  
trunk. It should all work there. Also you must do the gclient runhooks  
--force thing ...

I might be on #chromium later ... Drop by if you're still having  
trouble. That's easier than trying to solve it here...

--Craig

On 24 Apr 2009, at 15:55, nshah  wrote:

>
> actully I saw it there but then I was not sure if it needs another
> condition block for shared_library but before asking you again I
> wanted to try to build chrome (hammer app) and see if that works as
> you suggested.
>
> Thanks!
> Nidhi
>
> On Apr 24, 9:16 am, Craig Schlenter  wrote:
>> Hmmm ... actually it seems as if -ldl is present in
>> third_party/libxml/libxml.gyp ... so take a look if it's there for  
>> you
>> and run gclient sync if it isn't. Try running gclient runhooks -- 
>> force
>> if none of the other things work. Perhaps your scons files have not
>> been updated properly.
>>
>> --Craig
>>
>> On Fri, Apr 24, 2009 at 3:05 PM, Craig Schlenter
>>
>>  wrote:
>>> Hi
>>
>>> At some point I had used -ldl in the xml gyp file but then I dropped
>>> that when I purely
>>> targeted chrome and not any of the other targets ... in fact I  
>>> haven't
>>> even tried building
>>> the other targets for a while so it's quite possible that they won't
>>> build as shared targets.
>>
>>> Try
>>> hammer app
>>> and see if that works or add '-ldl' after '-lm' in libxml.gyp near  
>>> the
>>> xmlcatalog stuff.
>>
>>> Thanks!
>>
>>> --Craig
>>
>>> On Fri, Apr 24, 2009 at 2:26 PM, Dean McNamee   
>>> wrote:
>>
>>>> The obvious fix would be to add -ldl, but I don't see why libxml
>>>> should be using it...
>>
>>>> From a quick peek at the code, I saw xmlmodules.c using dlerror /  
>>>> etc
>>>> for dynamic module support.  Since libxml is running sandboxed,  
>>>> do we
>>>> really want dynamic module support?
>>
>>>> In specific, it seems like we have LIBXML_MODULES_ENABLED defined  
>>>> in
>>>> our xmlversion.h...
>>
>>>> On Fri, Apr 24, 2009 at 2:18 PM, nshah   
>>>> wrote:
>>
>>>>> This group is very impressive, always so quick in reply!
>>>>> Thanks for quick reply!
>>>>> I did hammer --verbose and here is the command if that helps:
>>
>>>>> cd /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ 
>>>>> src/base
>>>>> && ../chrome/tools/build/linux/version.sh
>>>>> file_version_info_linux.h.version /home/dev/ProgramFiles/v8/home/
>>>>> chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/
>>>>> global_intermediate/base/file_version_info_linux.h
>>>>> flock /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/ 
>>>>> src/
>>>>> sconsbuild/Debug/linker.lock gcc -o /home/dev/ProgramFiles/v8/ 
>>>>> home/
>>>>> chrome-svn/tarball/chromium/src/sconsbuild/Debug/xmlcatalog -L/ 
>>>>> home/
>>>>> dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/ 
>>>>> sconsbuild/
>>>>> Debug/lib -Wl,-rpath=/home/dev/ProgramFiles/v8/home/chrome-svn/ 
>>>>> tarball/
>>>>> chromium/src/sconsbuild/Debug/lib -m32 -pthread /home/dev/ 
>>>>> ProgramFiles/
>>>>> v8/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/
>>>>> third_party/libxml/xmlcatalog.o -Wl,--start-group -lm -lxml2 - 
>>>>> Wl,--end-
>>>>> group
>>>>> /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>>>> sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym'
>>>>> /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>>>> sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror'
>>>>> /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>>>> sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen'
>>>>> /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>>>> sconsbuild/Debug/lib/libxml2.

[chromium-dev] Re: gyp shared library builds on Linux

2009-04-24 Thread Craig Schlenter


Hmmm ... actually it seems as if -ldl is present in
third_party/libxml/libxml.gyp ... so take a look if it's there for you
and run gclient sync if it isn't. Try running gclient runhooks --force
if none of the other things work. Perhaps your scons files have not
been updated properly.

--Craig

On Fri, Apr 24, 2009 at 3:05 PM, Craig Schlenter
 wrote:
> Hi
>
> At some point I had used -ldl in the xml gyp file but then I dropped
> that when I purely
> targeted chrome and not any of the other targets ... in fact I haven't
> even tried building
> the other targets for a while so it's quite possible that they won't
> build as shared targets.
>
> Try
> hammer app
> and see if that works or add '-ldl' after '-lm' in libxml.gyp near the
> xmlcatalog stuff.
>
> Thanks!
>
> --Craig
>
> On Fri, Apr 24, 2009 at 2:26 PM, Dean McNamee  wrote:
>>
>> The obvious fix would be to add -ldl, but I don't see why libxml
>> should be using it...
>>
>> From a quick peek at the code, I saw xmlmodules.c using dlerror / etc
>> for dynamic module support.  Since libxml is running sandboxed, do we
>> really want dynamic module support?
>>
>> In specific, it seems like we have LIBXML_MODULES_ENABLED defined in
>> our xmlversion.h...
>>
>> On Fri, Apr 24, 2009 at 2:18 PM, nshah  wrote:
>>>
>>> This group is very impressive, always so quick in reply!
>>> Thanks for quick reply!
>>> I did hammer --verbose and here is the command if that helps:
>>>
>>> cd /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/base
>>> && ../chrome/tools/build/linux/version.sh
>>> file_version_info_linux.h.version /home/dev/ProgramFiles/v8/home/
>>> chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/
>>> global_intermediate/base/file_version_info_linux.h
>>> flock /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>> sconsbuild/Debug/linker.lock gcc -o /home/dev/ProgramFiles/v8/home/
>>> chrome-svn/tarball/chromium/src/sconsbuild/Debug/xmlcatalog -L/home/
>>> dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/sconsbuild/
>>> Debug/lib -Wl,-rpath=/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/
>>> chromium/src/sconsbuild/Debug/lib -m32 -pthread /home/dev/ProgramFiles/
>>> v8/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/
>>> third_party/libxml/xmlcatalog.o -Wl,--start-group -lm -lxml2 -Wl,--end-
>>> group
>>> /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>> sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym'
>>> /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>> sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror'
>>> /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>> sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen'
>>> /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>> sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose'
>>> collect2: ld returned 1 exit status
>>> scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>>> src/sconsbuild/Debug/xmlcatalog] Error 1
>>> gcc -o /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>> sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-tibetan.os -c -
>>> m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse -I/
>>> usr/include/freetype2 -O0 -g -fPIC -DCHROMIUM_BUILD -DTOOLKIT_GTK=1 -
>>> D_DEBUG -I/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>>> src/sconsbuild/Debug/obj/third_party/harfbuzz/src -I/home/dev/
>>> ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/third_party/
>>> harfbuzz/src /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/
>>> chromium/src/third_party/harfbuzz/src/harfbuzz-tibetan.c
>>> scons: building terminated because of errors.
>>>
>>> On Apr 24, 7:41 am, Dean McNamee  wrote:
>>>> Looks like it's missing -ldl, but I haven't looked closely.
>>>>
>>>> On Fri, Apr 24, 2009 at 12:57 PM, nshah  wrote:
>>>>
>>>> > hi there,
>>>>
>>>> > thanks for working on getting the shared lib of libraries! I was
>>>> > pointed to this work by Evan Martin as well and he pointed me to this
>>>> > (http://codereview.chromium.org/88058). However I am having some
>>>> > difficulty getting it to build and it errors out while building
>>>> > libxml.
>&

[chromium-dev] Re: gyp shared library builds on Linux

2009-04-24 Thread Craig Schlenter


Hi

At some point I had used -ldl in the xml gyp file but then I dropped
that when I purely
targeted chrome and not any of the other targets ... in fact I haven't
even tried building
the other targets for a while so it's quite possible that they won't
build as shared targets.

Try
hammer app
and see if that works or add '-ldl' after '-lm' in libxml.gyp near the
xmlcatalog stuff.

Thanks!

--Craig

On Fri, Apr 24, 2009 at 2:26 PM, Dean McNamee  wrote:
>
> The obvious fix would be to add -ldl, but I don't see why libxml
> should be using it...
>
> From a quick peek at the code, I saw xmlmodules.c using dlerror / etc
> for dynamic module support.  Since libxml is running sandboxed, do we
> really want dynamic module support?
>
> In specific, it seems like we have LIBXML_MODULES_ENABLED defined in
> our xmlversion.h...
>
> On Fri, Apr 24, 2009 at 2:18 PM, nshah  wrote:
>>
>> This group is very impressive, always so quick in reply!
>> Thanks for quick reply!
>> I did hammer --verbose and here is the command if that helps:
>>
>> cd /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/base
>> && ../chrome/tools/build/linux/version.sh
>> file_version_info_linux.h.version /home/dev/ProgramFiles/v8/home/
>> chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/
>> global_intermediate/base/file_version_info_linux.h
>> flock /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>> sconsbuild/Debug/linker.lock gcc -o /home/dev/ProgramFiles/v8/home/
>> chrome-svn/tarball/chromium/src/sconsbuild/Debug/xmlcatalog -L/home/
>> dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/sconsbuild/
>> Debug/lib -Wl,-rpath=/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/
>> chromium/src/sconsbuild/Debug/lib -m32 -pthread /home/dev/ProgramFiles/
>> v8/home/chrome-svn/tarball/chromium/src/sconsbuild/Debug/obj/
>> third_party/libxml/xmlcatalog.o -Wl,--start-group -lm -lxml2 -Wl,--end-
>> group
>> /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>> sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym'
>> /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>> sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror'
>> /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>> sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlopen'
>> /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>> sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlclose'
>> collect2: ld returned 1 exit status
>> scons: *** [/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> src/sconsbuild/Debug/xmlcatalog] Error 1
>> gcc -o /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>> sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-tibetan.os -c -
>> m32 -pthread -march=pentium4 -fno-exceptions -msse2 -mfpmath=sse -I/
>> usr/include/freetype2 -O0 -g -fPIC -DCHROMIUM_BUILD -DTOOLKIT_GTK=1 -
>> D_DEBUG -I/home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>> src/sconsbuild/Debug/obj/third_party/harfbuzz/src -I/home/dev/
>> ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/third_party/
>> harfbuzz/src /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/
>> chromium/src/third_party/harfbuzz/src/harfbuzz-tibetan.c
>> scons: building terminated because of errors.
>>
>> On Apr 24, 7:41 am, Dean McNamee  wrote:
>>> Looks like it's missing -ldl, but I haven't looked closely.
>>>
>>> On Fri, Apr 24, 2009 at 12:57 PM, nshah  wrote:
>>>
>>> > hi there,
>>>
>>> > thanks for working on getting the shared lib of libraries! I was
>>> > pointed to this work by Evan Martin as well and he pointed me to this
>>> > (http://codereview.chromium.org/88058). However I am having some
>>> > difficulty getting it to build and it errors out while building
>>> > libxml.
>>>
>>> > ==
>>> > ...
>>> > Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>>> > src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-gsub.os
>>> > Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>> > sconsbuild/Debug/lib/libxml2.so
>>> > Linking /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>> > sconsbuild/Debug/xmlcatalog
>>> > Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>>> > src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-impl.os
>>> > Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>>> > src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-open.os
>>> > Compiling /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/
>>> > src/sconsbuild/Debug/obj/third_party/harfbuzz/src/harfbuzz-shaper.os
>>> > /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>> > sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlsym'
>>> > /home/dev/ProgramFiles/v8/home/chrome-svn/tarball/chromium/src/
>>> > sconsbuild/Debug/lib/libxml2.so: undefined reference to `dlerror'
>>> > /home/dev/ProgramFiles

[chromium-dev] Re: cryptoht.h not found

2009-04-20 Thread Craig Schlenter


On Mon, Apr 20, 2009 at 4:55 PM, Evan Martin  wrote:
[snip]
> Maybe now that gyp is settled and most of temporary_link_stubs is gone
> we could reinvestigate dynamic linking...

It's working for me:

http://codereview.chromium.org/67207 (changes to gyp itself, not really right)
http://codereview.chromium.org/67212 (random other missing bits and pieces)

Those changes are enough to get chrome working. The changes for test_shell
etc. are also pretty easy but I doubt there's much interest in that so I haven't
pushed that into review yet...

--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: cryptoht.h not found

2009-04-20 Thread Craig Schlenter


Hi

Dynamic linking is not an option yet but it's being worked on. For now
you should either use gold as the linker (see the wiki about faster
linux builds) or perhaps try adding tons of swap space and take an
extended holiday while you wait for it to link.

--Craig

On Mon, Apr 20, 2009 at 10:00 AM, Hassan Rom  wrote:
> Thanks! Mohamed's suggestion worked fine, but now I'm getting a not enough
> memory error while linking. How do I get it to link dynamically instead?
> Presumably, linking dynamically would require less memory.
>
> - HR
>
> [error I'm getting..]
> flock /home/hassan/devel/chromium/src/sconsbuild/Debug/linker.lock g++ -o
> /home/hassan/devel/chromium/src/sconsbuild/Debug/chrome -m32 -pthread
> /home/hassan/devel/chromium/src/sconsbuild/Debug/obj/chrome/app/chrome_dll_main.o
> /home/hassan/devel/chromium/src/sconsbuild/Debug/obj/chrome/app/chrome_exe_main_gtk.o
> -L/home/hassan/devel/chromium/src/sconsbuild/Debug/lib -Wl,--start-group
> -lX11 -lXrender -lXext -lrt -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
> -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0
> -lgmodule-2.0 -ldl -lglib-2.0 -lnss3 -lnssutil3 -lsmime3 -lssl3 -lplds4
> -lplc4 -lnspr4 -lpthread -ldl -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm
> -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl
> -lglib-2.0 -lfontconfig -lfreetype -lz -lrt -lcommon -lbrowser -lrenderer
> -lprinting -lviews -lbase -licui18n -licuuc -licudata -levent -lbase_gfx
> -lskia -lharfbuzz -lharfbuzz_interface -ljpeg -lpng -lz -lgoogleurl -lnet
> -lv8 -lv8_base -lsdch -lbz2 -lmodp_b64 -lxml2 -lglue -lwebcore -lpcre -lwtf
> -lxslt -lsqlite3 -lwebkit -lmedia -lhunspell -Wl,--end-group
> /lib/ld-linux.so.2: could not read symbols: Memory exhausted
> collect2: ld returned 1 exit status
>
>
> On Mon, Apr 20, 2009 at 7:25 AM, Craig Schlenter 
> wrote:
>>
>> Hi
>>
>> AFAIK the build system runs 'pkg-config --cflags nss'  or something to
>> figure out the correct paths. I'd poke at that to see if it yields any
>> clues if Mohamed's suggestions don't help.
>>
>> See build/linux/system.gyp btw.
>>
>> --Craig
>>
>> On Mon, Apr 20, 2009 at 6:47 AM, Mohamed Mansour
>>  wrote:
>> > Hi, can you try running, gclient runhooks --force, gclient sync --force,
>> >  clobber (delete build directory), and build again.
>> >
>> > On Sun, Apr 19, 2009 at 5:59 PM, Hassan  wrote:
>> >>
>> >> Hello,
>> >>
>> >> I can't seem to compile chrome on my linux machine. It's complaining
>> >> that it couldn't find cryptoht.h (see below). After some digging, I
>> >> noticed g++ is possibly missing a -I/usr/include/nss flag since it
>> >> seems that cryptoht.h lives in /usr/include/nss/:
>> >>
>> >> has...@hassan-desktop:~/devel/chromium/src/build$ locate cryptoht.h
>> >> /usr/include/nss/cryptoht.h
>> >>
>> >> Could this be the reason? If so, what is the correct way of including
>> >> that flag to g++?
>> >>
>> >> Thanks,
>> >> - HR
>> >>
>> >> Here is the error message that I'm getting when compiling:
>> >> has...@hassan-desktop:~/devel/chromium/src/build$ ../../depot_tools/
>> >> hammer app --verbose
>> >> scons: Reading SConscript files ...
>> >> scons: done reading SConscript files.
>> >> scons: Building targets ...
>> >> cd /home/hassan/devel/chromium/src/base && ../chrome/tools/build/linux/
>> >> version.sh file_version_info_linux.h.version /home/hassan/devel/
>> >> chromium/src/sconsbuild/Debug/obj/global_intermediate/base/
>> >> file_version_info_linux.h
>> >> g++ -o /home/hassan/devel/chromium/src/sconsbuild/Debug/obj/base/
>> >> crypto/signature_verifier_nss.o -c -m32 -pthread -march=pentium4 -fno-
>> >> exceptions -msse2 -mfpmath=sse -Wall -Wno-write-strings -I/usr/include/
>> >> gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/
>> >> include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/
>> >> lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -
>> >> I/usr/include/pixman-1 -O0 -g -DCHROMIUM_BUILD -DTOOLKIT_GTK=1 -
>> >> DU_STATIC_IMPLEMENTATION -D_DEBUG -I/home/hassan/devel/chromium/src/
>> >> sconsbuild/Debug/obj/third_party/icu38/public/common -I/home/hassan/
>> >> devel/chromium/src/third_party/icu38/public/common -I/home/hassan/
>> >> devel/chromium/src/sconsbuild/Debug/obj/third_pa

[chromium-dev] Re: cryptoht.h not found

2009-04-19 Thread Craig Schlenter


Hi

AFAIK the build system runs 'pkg-config --cflags nss'  or something to
figure out the correct paths. I'd poke at that to see if it yields any
clues if Mohamed's suggestions don't help.

See build/linux/system.gyp btw.

--Craig

On Mon, Apr 20, 2009 at 6:47 AM, Mohamed Mansour
 wrote:
> Hi, can you try running, gclient runhooks --force, gclient sync --force,
>  clobber (delete build directory), and build again.
>
> On Sun, Apr 19, 2009 at 5:59 PM, Hassan  wrote:
>>
>> Hello,
>>
>> I can't seem to compile chrome on my linux machine. It's complaining
>> that it couldn't find cryptoht.h (see below). After some digging, I
>> noticed g++ is possibly missing a -I/usr/include/nss flag since it
>> seems that cryptoht.h lives in /usr/include/nss/:
>>
>> has...@hassan-desktop:~/devel/chromium/src/build$ locate cryptoht.h
>> /usr/include/nss/cryptoht.h
>>
>> Could this be the reason? If so, what is the correct way of including
>> that flag to g++?
>>
>> Thanks,
>> - HR
>>
>> Here is the error message that I'm getting when compiling:
>> has...@hassan-desktop:~/devel/chromium/src/build$ ../../depot_tools/
>> hammer app --verbose
>> scons: Reading SConscript files ...
>> scons: done reading SConscript files.
>> scons: Building targets ...
>> cd /home/hassan/devel/chromium/src/base && ../chrome/tools/build/linux/
>> version.sh file_version_info_linux.h.version /home/hassan/devel/
>> chromium/src/sconsbuild/Debug/obj/global_intermediate/base/
>> file_version_info_linux.h
>> g++ -o /home/hassan/devel/chromium/src/sconsbuild/Debug/obj/base/
>> crypto/signature_verifier_nss.o -c -m32 -pthread -march=pentium4 -fno-
>> exceptions -msse2 -mfpmath=sse -Wall -Wno-write-strings -I/usr/include/
>> gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/
>> include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/
>> lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -
>> I/usr/include/pixman-1 -O0 -g -DCHROMIUM_BUILD -DTOOLKIT_GTK=1 -
>> DU_STATIC_IMPLEMENTATION -D_DEBUG -I/home/hassan/devel/chromium/src/
>> sconsbuild/Debug/obj/third_party/icu38/public/common -I/home/hassan/
>> devel/chromium/src/third_party/icu38/public/common -I/home/hassan/
>> devel/chromium/src/sconsbuild/Debug/obj/third_party/icu38/public/i18n -
>> I/home/hassan/devel/chromium/src/third_party/icu38/public/i18n -I/home/
>> hassan/devel/chromium/src/sconsbuild/Debug/obj -I/home/hassan/devel/
>> chromium/src -I/home/hassan/devel/chromium/src/sconsbuild/Debug/obj/
>> global_intermediate -I/home/hassan/devel/chromium/src/
>> global_intermediate /home/hassan/devel/chromium/src/base/crypto/
>> signature_verifier_nss.cc
>> g++ -o /home/hassan/devel/chromium/src/sconsbuild/Debug/obj/base/
>> file_util_posix.o -c -m32 -pthread -march=pentium4 -fno-exceptions -
>> msse2 -mfpmath=sse -Wall -Wno-write-strings -I/usr/include/gtk-2.0 -I/
>> usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/
>> usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/
>> include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/
>> include/pixman-1 -O0 -g -DCHROMIUM_BUILD -DTOOLKIT_GTK=1 -
>> DU_STATIC_IMPLEMENTATION -D_DEBUG -I/home/hassan/devel/chromium/src/
>> sconsbuild/Debug/obj/third_party/icu38/public/common -I/home/hassan/
>> devel/chromium/src/third_party/icu38/public/common -I/home/hassan/
>> devel/chromium/src/sconsbuild/Debug/obj/third_party/icu38/public/i18n -
>> I/home/hassan/devel/chromium/src/third_party/icu38/public/i18n -I/home/
>> hassan/devel/chromium/src/sconsbuild/Debug/obj -I/home/hassan/devel/
>> chromium/src -I/home/hassan/devel/chromium/src/sconsbuild/Debug/obj/
>> global_intermediate -I/home/hassan/devel/chromium/src/
>> global_intermediate /home/hassan/devel/chromium/src/base/
>> file_util_posix.cc
>> In file included from /home/hassan/devel/chromium/src/base/crypto/
>> signature_verifier_nss.cc:5:
>> /home/hassan/devel/chromium/src/base/crypto/signature_verifier.h:
>> 11:22: error: cryptoht.h: No such file or directory
>> /home/hassan/devel/chromium/src/base/crypto/signature_verifier_nss.cc:
>> 7:22: error: cryptohi.h: No such file or directory
>> /home/hassan/devel/chromium/src/base/crypto/signature_verifier_nss.cc:
>> 8:19: error: keyhi.h: No such file or directory
>> ...
>>
>> And the version of Ubuntu and kernal I am running:
>> has...@hassan-desktop:~/devel/chromium/src/build$ lsb_release -a
>> No LSB modules are available.
>> Distributor ID: Ubuntu
>> Description:    Ubuntu 8.04.2
>> Release:        8.04
>> Codename:       hardy
>> has...@hassan-desktop:~/devel/chromium/src/build$ uname -a
>> Linux hassan-desktop 2.6.24-23-generic #1 SMP Wed Apr 1 21:47:28 UTC
>> 2009 i686 GNU/Linux
>>
>>
>
>
> 

--~--~-~--~~~---~--~~
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: gyp build on Linux

2009-04-02 Thread Craig Schlenter

On Thu, Apr 2, 2009 at 5:43 PM, Mark Mentovai  wrote:
> Craig Schlenter wrote:
>> When I add -Wl,--start-group and -Wl,--end-group to that (manually
>> since haven't figured out how to make gyp do it), then the missing
>> symbol problem goes away (at least when loading chrome and navigating
>> to mail.google which is where I was seeing the problem).
>
> I don't know that there should be circular dependencies any more.
> Between what modules are you seeing them?  We can do a workaround
> temporarily if needed, but I'm very interested in actually fixing any
> circular relationships.

For me it showed up as a missing symbol when loading the test plugin in chrome:

[5209:5223:162087104802:FATAL:/home/craig/chromium.git/src/webkit/glue/plugins/plugin_lib_linux.cc(27)]
Check failed: false. dlopen failed:
/home/craig/chromium.git/src/sconsbuild/Debug/plugins/libnpapi_test_plugin.so:
undefined symbol: _ZN7icu_3_813UnicodeString4trimEv
[5209:5223:162087104802:FATAL:/home/craig/chromium.git/src/webkit/glue/plugins/plugin_lib_linux.cc(27)]
Check failed: false. dlopen failed:
/home/craig/chromium.git/src/sconsbuild/Debug/plugins/libnpapi_test_plugin.so:
undefined symbol: _ZN7icu_3_813UnicodeString4trimEv
Trace/breakpoint trap

Dean mentioned that the buildbots have a very similar ICU issue:

http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/6601/steps/test_shell_tests/logs/MimeTypeTests

--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: gyp build on Linux

2009-04-02 Thread Craig Schlenter


On Thu, Apr 2, 2009 at 4:47 PM, Craig Schlenter
 wrote:
> Just a wild guess but I think it's missing the circular linker magic
> start/end stuff when compiling the plugin. Will try to confirm when I'm near
> a pc again ...

Confirmed. Here's the line it's using to generate the plugin on my machine:

g++ -o 
/home/craig/chromium.git/src/sconsbuild/Debug/plugins/libnpapi_test_plugin.so
-m32 -pthread -shared
/home/craig/chromium.git/src/sconsbuild/Debug/obj/webkit/glue/plugins/test/npapi_constants.os
/home/craig/chromium.git/src/sconsbuild/Debug/obj/webkit/glue/plugins/test/npapi_test.os
/home/craig/chromium.git/src/sconsbuild/Debug/obj/webkit/glue/plugins/test/plugin_arguments_test.os
/home/craig/chromium.git/src/sconsbuild/Debug/obj/webkit/glue/plugins/test/plugin_delete_plugin_in_stream_test.os
/home/craig/chromium.git/src/sconsbuild/Debug/obj/webkit/glue/plugins/test/plugin_get_javascript_url_test.os
/home/craig/chromium.git/src/sconsbuild/Debug/obj/webkit/glue/plugins/test/plugin_geturl_test.os
/home/craig/chromium.git/src/sconsbuild/Debug/obj/webkit/glue/plugins/test/plugin_new_fails_test.os
/home/craig/chromium.git/src/sconsbuild/Debug/obj/webkit/glue/plugins/test/plugin_npobject_proxy_test.os
/home/craig/chromium.git/src/sconsbuild/Debug/obj/webkit/glue/plugins/test/plugin_test.os
-L/home/craig/chromium.git/src/sconsbuild/Debug/lib -lrt -lgtk-x11-2.0
-lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0
-lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 -lssl3 -lsmime3
-lnss3 -lnssutil3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -lbase -licuuc
-licui18n -licudata -levent

When I add -Wl,--start-group and -Wl,--end-group to that (manually
since haven't figured out how to make gyp do it), then the missing
symbol problem goes away (at least when loading chrome and navigating
to mail.google which is where I was seeing the problem).

HTH,

--Craig

> On 02 Apr 2009, at 15:48, Dean McNamee  wrote:
>
>>
>> I confirmed the debug build line has no -g.
>>
>> Also, all of the buildbots are red because of ICU issues:
>>
>>
>> http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/6601/steps/test_shell_tests/logs/MimeTypeTests
>>
>> On Thu, Apr 2, 2009 at 3:46 PM, Dan Kegel 
>> wrote:
>>>
>>> And it seems to be built without debugging flags in debug mode.
>>> At least, I can't single-step through code on Linux.
>>>
>>> On Thu, Apr 2, 2009 at 4:18 AM, Dean McNamee  wrote:
>>>>
>>>> (this isn't just V8, all of chromium is built without optimization in
>>>> release).  There are lots of other issues all over the place.
>>>>
>>>> On Thu, Apr 2, 2009 at 1:14 PM, Dean McNamee  wrote:
>>>>>
>>>>> Notice the lack of -O2, etc.  This also broke SYMBOLS= PROFILE=,
>>>>> COVERAGE=, etc.
>>>>>
>>>>> I am tempted to revert it all.
>>>
>>
>> >>
>

--~--~-~--~~~---~--~~
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: gyp build on Linux

2009-04-02 Thread Craig Schlenter


Just a wild guess but I think it's missing the circular linker magic  
start/end stuff when compiling the plugin. Will try to confirm when  
I'm near a pc again ...

--Craig

On 02 Apr 2009, at 15:48, Dean McNamee  wrote:

>
> I confirmed the debug build line has no -g.
>
> Also, all of the buildbots are red because of ICU issues:
>
> http://build.chromium.org/buildbot/waterfall/builders/Modules%20Linux%20(dbg)/builds/6601/steps/test_shell_tests/logs/MimeTypeTests
>
> On Thu, Apr 2, 2009 at 3:46 PM, Dan Kegel   
> wrote:
>> And it seems to be built without debugging flags in debug mode.
>> At least, I can't single-step through code on Linux.
>>
>> On Thu, Apr 2, 2009 at 4:18 AM, Dean McNamee   
>> wrote:
>>> (this isn't just V8, all of chromium is built without optimization  
>>> in
>>> release).  There are lots of other issues all over the place.
>>>
>>> On Thu, Apr 2, 2009 at 1:14 PM, Dean McNamee   
>>> wrote:
 Notice the lack of -O2, etc.  This also broke SYMBOLS= PROFILE=,  
 COVERAGE=, etc.

 I am tempted to revert it all.
>>
>
> >

--~--~-~--~~~---~--~~
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: Chromium App Executables Disk Layout

2009-03-24 Thread Craig Schlenter

On Tue, Mar 24, 2009 at 8:45 PM, Thomas Van Lenten
 wrote:
[snip]
> Linux currently builds as one executable also.  But Adam proposed we create
> a second executable (via hardlink?) for AppArmor as a sandbox?

Will a hard link work for selinux btw.? I'm under the impression that
selinux is inode based so Fedora etc. would have to do something
different there.

As for the shared library overhead that Dean mentioned, there is some
interesting work on linux that is mentioned here
http://lwn.net/Articles/192624/ ... hopefully some of that has made it
into the default toolchain by now.

Pre-linking is enabled by default on Fedora btw. ... I'm unsure of
other distributions.

--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: ResourceMessageFilter::OnGet(Root)WindowRect and NULL windows

2009-03-23 Thread Craig Schlenter


On Mon, Mar 23, 2009 at 6:45 PM, Darin Fisher  wrote:
> Thanks for the info!  Could you dump this into a bug report?

Added to http://crbug.com/9060 ...

--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: ResourceMessageFilter::OnGet(Root)WindowRect and NULL windows

2009-03-23 Thread Craig Schlenter

On Sun, Mar 22, 2009 at 1:01 AM, Darin Fisher  wrote:
> It would be nice to track down the source of the null NativeViewId.  I bet
> that corresponds to a real bug.

Here's a backtrace from the renderer with host_window_ == NULL
obtained from clicking on a link in an email in gmail:

(gdb) bt
#0  RenderWidget::GetRootWindowRect (this=0x9330530,
webwidget=0x932ffc0, rect=0xb77b4508) at renderer/render_widget.cc:602
#1  0x011808f1 in ChromeClientImpl::windowRect (this=0x90b76b8) at
/home/craig/chromium.git/src/webkit/glue/chrome_client_impl.cc:100
#2  0x07692c3c in WebCore::Chrome::windowRect (this=0x9338000) at
/home/craig/chromium.git/src/third_party/WebKit/WebCore/page/Chrome.cpp:119
#3  0x07a435e7 in WebCore::FrameLoader::createWindow (this=0x8b3715c,
frameLoaderForFrameLookup=0x8a6caac, reque...@0xb77b47b4,
featur...@0xb77b4b54,
creat...@0xb77b4abb) at
/home/craig/chromium.git/src/third_party/WebKit/WebCore/loader/FrameLoader.cpp:380
#4  0x0444ec13 in createWindow (openerFrame=0x8a6ca80,
u...@0xb77b4bcc, framena...@0xb77b4bc8, windowfeatur...@0xb77b4b54,
dialogArgs=
{> = {val_ = 0x0}, })
at 
/home/craig/chromium.git/src/third_party/WebKit/WebCore/bindings/v8/custom/V8DOMWindowCustom.cpp:270
#5  0x0444fee0 in WebCore::V8Custom::v8DOMWindowOpenCallback (ar...@0xb77b4ce4)
at 
/home/craig/chromium.git/src/third_party/WebKit/WebCore/bindings/v8/custom/V8DOMWindowCustom.cpp:492
#6  0x0806e20d in Builtin_HandleApiCall (__argc__=4,
__argv__=0xb77b4da0) at
/home/craig/chromium.git/src/v8/src/builtins.cc:380

After poking at some code and inserting the odd printf, it seems as if
RenderView::CreateWebView is calling RenderView::Create and passing a
_hardcoded_ NULL as the parent_hwnd which is then passed to
RenderView::Init where host_window_ is set to parent_hwnd which is
NULL. That NULL would seem to me to be wrong. If it's not wrong, the
other  initialisation path for host_window_ is
RenderWidget::CompleteInit which is called from
RenderWidget::OnCreatingNewAck. The CreatingNewAck message should be
sent by RenderWidgetHost::Init() but I never see that being called
when creating the error.

Hopefully that's enough detail for someone who actually understands
what these things do to propose a fix :)

It looks trivial to squash sending the NULL to the browser to in
RenderWidget::GetRootWindowRect but that is probably not the right
fix.

Thank you,

--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: ResourceMessageFilter::OnGet(Root)WindowRect and NULL windows

2009-03-19 Thread Craig Schlenter


Hi

OK, that's interesting, thank you.  Does GetAncestor return something
valid when passed that null HWND or does it pass null through to
GetwindowRect? It would also be interesting to know what rect it
returns please. Maybe it doesn't matter ... I haven't looked at the
renderer code that creates this request to see if it actually cares
about this when the window is null.

Thank you,

--Craig

On Thu, Mar 19, 2009 at 7:56 PM, Mohamed Mansour
 wrote:
> Craig, it returns back a 0.
> +               window  0x {unused=??? }        HWND__ *
>
>
>
>
> On Thu, Mar 19, 2009 at 1:46 PM, Craig Schlenter
>  wrote:
>>
>> Hi Avi
>>
>> When I did the original change, that function wasn't being called with
>> a null window.
>> Clicking on a link in gmail opened the link in a new window as I
>> recall. At some later
>> point that changed possibly when some of the tab_contents stuff was hooked 
>> up. I
>> think it's good practice to check for null since you don't want the
>> renderer to be able
>> to crash the browser but I do tend to think that it shouldn't be
>> happening to begin with
>> but I'm largely clueless about the code involved :(
>>
>> Perhaps someone with a windows build can put a breakpoint in
>> OnGetRootWindowRect please and see if clicking on a link in an
>> email in gmail passes a HWND of null at all?
>>
>> Thank you,
>>
>> --Craig
>>
>> On Thu, Mar 19, 2009 at 7:33 PM, Avi Drissman  wrote:
>>> We've been seeing calls to ResourceMessageFilter::OnGet(Root)WindowRect for
>>> NULL windows. agl put in a fix for GTK with
>>> http://codereview.chromium.org/42356 and I'm seeing the same problem on the
>>> Mac.
>>>
>>> 1. Why isn't Windows seeing this? What happens when you pass a null HWND
>>> into ::GetAncestor and ::GetWindowRect?
>>> 2. Is this expected, or is this indicative of a bug?
>>>
>>> Avi
>>>
>>
>> >>
>>
>

--~--~-~--~~~---~--~~
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: ResourceMessageFilter::OnGet(Root)WindowRect and NULL windows

2009-03-19 Thread Craig Schlenter

Hi Avi

When I did the original change, that function wasn't being called with
a null window.
Clicking on a link in gmail opened the link in a new window as I
recall. At some later
point that changed possibly when some of the tab_contents stuff was hooked up. I
think it's good practice to check for null since you don't want the
renderer to be able
to crash the browser but I do tend to think that it shouldn't be
happening to begin with
but I'm largely clueless about the code involved :(

Perhaps someone with a windows build can put a breakpoint in
OnGetRootWindowRect please and see if clicking on a link in an
email in gmail passes a HWND of null at all?

Thank you,

--Craig

On Thu, Mar 19, 2009 at 7:33 PM, Avi Drissman  wrote:
> We've been seeing calls to ResourceMessageFilter::OnGet(Root)WindowRect for
> NULL windows. agl put in a fix for GTK with
> http://codereview.chromium.org/42356 and I'm seeing the same problem on the
> Mac.
>
> 1. Why isn't Windows seeing this? What happens when you pass a null HWND
> into ::GetAncestor and ::GetWindowRect?
> 2. Is this expected, or is this indicative of a bug?
>
> Avi
>

--~--~-~--~~~---~--~~
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: linux async IO

2009-02-25 Thread Craig Schlenter


On Wed, Feb 25, 2009 at 11:21 PM, Adam Langley  wrote:
>
> On Wed, Feb 25, 2009 at 1:13 PM, William Chan (陈智昌)
>  wrote:
>> I talked to Darin and he told me that this needs work since it's
>> impacting the page cycler times, so I figured I'd pick it up.  You
>> have a TODO there saying to figure out how to best do async IO.  Did
>> you ever figure this out?  I talked to Darin briefly and decided that
>> the simplest thing to do for now is simply to post tasks to the global
>> WorkerPool.  The global WorkerPool linux implementation looks pretty
>> silly and needs work, but it's probably good enough for the page
>> cycler.  How does this approach sound to you?
>
> It's not clear if you were considering using POSIX async IO on Linux
> or not. Just in case you were: don't. It mostly doesn't work.

LWN has a nice article on the future of async IO on linux here btw.

http://lwn.net/Articles/316806/

Unfortunately that's not that useful currently.

--Craig

--~--~-~--~~~---~--~~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
http://groups.google.com/group/chromium-dev
-~--~~~~--~~--~--~---

49 matches

Mail list logo