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 wa
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/51903
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
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://coder
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
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 #3
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.o
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: N
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
old 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,
ich 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/200
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 F
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/Deb
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 pro
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
-
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 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 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 Tu
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:
>> &g
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
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
> wro
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
--
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
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
>> o
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 goo
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
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 c
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
perh
n 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 ...
>
&g
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 i
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
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
+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 &q
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:
>
-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 oth
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 s
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.c
: 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 ou
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
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 c
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
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 buildb
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 b
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, c
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
> 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
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 fo
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 o
49 matches
Mail list logo
