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

[hap 497]

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:
$ df
Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/sda1 14784680  10044024   3989620  72% /
udev383892   216383676   1% /dev
none383892   360383532   1% /dev/shm
none38389292383800   1% /var/run
none383892 0383892   0% /var/lock
none383892 0383892   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-dev] Re: heads up: Rietveld reply by email isn't working

[John Abd-El-Malek]

Note: this should be working again now.  We decided to put the issue numbers
in the subject line like Mondrian (but at the end, as to not conflict with
bug numbers which are put at the front of Python bug mail).

On Thu, Nov 19, 2009 at 11:40 AM, John Abd-El-Malek wrote:

> There is a bug in App Engine with some new APIs that we're using.  I'm
> working on a workaround with another outside contributor which will
> hopefully land in a day or two.  Until then, if you care about your reply
> showing up on Rietveld, don't reply by email.

-- 
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] workflow for cross-platform development

[Paweł Hajdan Jr .]

On Sat, Nov 21, 2009 at 19:52, Chris Bentzel  wrote:

> Have there been any thoughts about adding gcl patch and unpatch commands
> which will grab the file diffs as well as duplicate the CL metadata in
> src/.svn/gcl_info?
>

It's not trivial to correctly apply a patch in svn (file moves, property
changes, merge conflicts, etc). With git-cl, you can just say git cl
, and it will do what you want.

-- 
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] Singleton shenanigans in base/time_win.cc causing problems (not the first time)

[Paweł Hajdan Jr .]

On Mon, Nov 23, 2009 at 02:22, Marc-Antoine Ruel  wrote:

> It's really about the unit tests, not in chromium.
>
> I guess we could probably leak the singleton in the unit tests too on
> each reset. Pawel, what do you think?
>
> Note to all the static local makers: you create an implicit atexit()
> each time... Use a leaky singleton instead.


That was my first though as well, but it won't fix the problem really. If a
Singleton touches a MessageLoop, we're going to have bad problems in tests
(because we create and re-instantiate it for different tests, and some tests
don't have MessageLoop at all). And SystemMonitor does, and has to.

SystemMonitor makes one assumption that we can't really where it is
currently: that one MessageLoop is always running through its lifetime. I
have a patch ready (have to submit it yet) that moves SystemMonitor to
chrome/common, as well as HighResolutionTimerManager, and de-Singletonizes
them. They have to be instantiated where currently SystemMonitor::Enable is
called. I verified that we don't get the bad problems that we currently have
with that.

If it doesn't convince you... SystemMonitor was a LeakySingleton. And it
still caused problems because of its assumption that the same MessageLoop
exists through its lifetime. I think that moving it to a place where we can
make that assumption valid is the proper fix.

Another (slightly weird maybe) solution would be to have a per-thread
SystemMonitor, lazily created. Then we could just use ObserverList, which
doesn't use MessageLoop. But IMHO it is more complex than the proposed
solution above, and may have its own problems.

What do you think?

-- 
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] workflow for cross-platform development

[Robert Sesek]

On Sat, Nov 21, 2009 at 1:52 PM, Chris Bentzel  wrote:

> Do you mostly rely on the try-bots, or do you also patch the diffs to your
> different dev environments and build and test locally?
>
> If you do the patching, do you tend to do a gcl upload and grab the diffs
> from there, or do you copy the diffs from machine to machine prior to the
> upload? If you do an initial gcl upload, do you skip the trybots until you
> validate that it works on all platforms to reduce load on the trybots?
>

The try bots are helpful, but it's often nice to be able to attach a
debugger or to locally build things you're not sure about. Cross-machine
work is greatly eased by using
git because
you can push/pull local-only commits to/from different repositories. I also
keep my one main machine as the one to actually perform Rietveld uploads and
commits on.

rsesek / @chromium.org

-- 
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] workflow for cross-platform development

[Dirk Pranke]

On Sat, Nov 21, 2009 at 10:52 AM, Chris Bentzel  wrote:
> How do most people do cross-platform validation prior to submitting code?
> Do you mostly rely on the try-bots, or do you also patch the diffs to your
> different dev environments and build and test locally?

I build on the different environments and test locally when I am doing
something that I know
is very platform specific (like tweaking code that changes layout test
baselines). I think I am unusual in this regard.

Otherwise I tend to use the trybots.

> If you do the patching, do you tend to do a gcl upload and grab the diffs
> from there, or do you copy the diffs from machine to machine prior to the
> upload? If you do an initial gcl upload, do you skip the trybots until you
> validate that it works on all platforms to reduce load on the trybots?

It depends. Sometimes I will use rietveld (gcl upload) as a way to
checkpoint progress, in which case I will skip the trybots
until I'm ready (usually. sometimes I forget). I usually compute the
diffs myself and move them between machines. I have
found rietveld's diffs to be a bit unreliable :(

> Have there been any thoughts about adding gcl patch and unpatch commands
> which will grab the file diffs as well as duplicate the CL metadata in
> src/.svn/gcl_info?

Not as far as I know, but that would be really cool. Feel free to add a patch :)

-- Dirk

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

[chromium-dev] workflow for cross-platform development

[Chris Bentzel]

How do most people do cross-platform validation prior to submitting code?

Do you mostly rely on the try-bots, or do you also patch the diffs to your
different dev environments and build and test locally?

If you do the patching, do you tend to do a gcl upload and grab the diffs
from there, or do you copy the diffs from machine to machine prior to the
upload? If you do an initial gcl upload, do you skip the trybots until you
validate that it works on all platforms to reduce load on the trybots?

Have there been any thoughts about adding gcl patch and unpatch commands
which will grab the file diffs as well as duplicate the CL metadata in
src/.svn/gcl_info?

Sorry if this is a FAQ - but I couldn't find anything covering this on
dev.chromium.org or by searching the chromium-dev group archive.

Chris

-- 
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] Singleton shenanigans in base/time_win.cc causing problems (not the first time)

[Darin Fisher]

We could define a function that must be called before you can use code in
base/.  You could add a call to this everywhere that we currently create the
AtExitManager.  Or, maybe we could combine those somehow.

I don't think lazy initialization of stuff like this is all that valuable.
 It is complexity for no real benefit.

-Darin


On Fri, Nov 20, 2009 at 1:44 PM, Paweł Hajdan Jr.
wrote:

> Do you have some idea how to get rid of the Singletons in base/time_win.cc?
> They don't play very well with base::SystemMonitor, MessageLoop, and test
> code.
>
> Here's the scenario we're hitting right now (in browser_tests):
>
> 1. HighResolutionTimerManager is created to enable high resolution timer
> unconditionally. An AtExit callback is created to destroy it.
> 2. The main MessageLoop is created. Its LazyInstance initializes a
> ThreadLocalPointer, which gets assigned the pointer to the MessageLoop. An
> AtExit callback is registered to reset the LazyInstance to the initial
> state.
> 3. BrowserMain enables monitoring SystemMonitor in
> HighResolutionTimerManager.
> 4. Which makes HighResolutionTimerManager register as a SystemMonitor
> observer.
>
> If everything seems OK so far, you're almost right. It's perfectly fine
> when browser runs, but has surprising "special effects" when test code runs.
> Here's what happens:
>
> 1. MessageLoop is destroyed. Its ThreadLocalPointer is set to NULL.
> 2. AtExit callbacks start to execute.
> 3. HighResolutionTimerManager is destroyed first. Its StopMonitoring method
> is called from dtor, which in turn touches MessageLoop::current(), which
> touches LazyInstance and makes it re-initialize itself, which registers
> AtExit callbacks which causes a DCHECK failure, because we're already
> processing AtExit callbacks.
>
> Don't worry too much if the explanation above is unclear (I'm afraid it
> is). The point is, it's not the first time that a nasty bug happens with
> SystemMonitor and the time_win.cc Singletons. Earlier it was different, so
> it's not so much important in what particular way it failed now.
>
> I'd really love to get rid of these Singletons. Do you have any ideas? We
> have two things here:
>
> 1) NowSingleton which keeps track of Windows time rollover. This might be
> harder to remove, but isn't causing too many problems.
> 2) HighResolutionTimerManager is causing problems. It was previously part
> of NowSingleton. I extracted the most evil part of it, and this is the
> current HRTM. I'm thinking about hardwiring it with the SystemMonitor or
> making it a Leaky Singleton maybe...
>
> --
> 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] Singleton shenanigans in base/time_win.cc causing problems (not the first time)

[Marc-Antoine Ruel]

It's really about the unit tests, not in chromium.

I guess we could probably leak the singleton in the unit tests too on
each reset. Pawel, what do you think?

Note to all the static local makers: you create an implicit atexit()
each time... Use a leaky singleton instead.

M-A

On Sun, Nov 22, 2009 at 7:47 PM, Peter Kasting  wrote:
> On Sun, Nov 22, 2009 at 4:28 PM, Mike Belshe  wrote:
>>
>> I think we should have a list of low-level functionality which we just
>> never cleanup.
>> For the items you listed, I think you should leak them all.  Trying to
>> cleanup these items creates complicated code and ultimately won't run any
>> better and possibly slower.
>
> +1 for leaking a much as possible on shutdown.  We should make sure we shut
> down anything that can write data to disk, and then just kill the process.
>  Right now I suspect we clean up much more stuff in the browser process than
> we have to.
> PK
>
> --
> 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] Singleton shenanigans in base/time_win.cc causing problems (not the first time)

[Peter Kasting]

On Sun, Nov 22, 2009 at 4:28 PM, Mike Belshe  wrote:

> I think we should have a list of low-level functionality which we just
> never cleanup.
>
> For the items you listed, I think you should leak them all.  Trying to
> cleanup these items creates complicated code and ultimately won't run any
> better and possibly slower.
>

+1 for leaking a much as possible on shutdown.  We should make sure we shut
down anything that can write data to disk, and then just kill the process.
 Right now I suspect we clean up much more stuff in the browser process than
we have to.

PK

-- 
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] Singleton shenanigans in base/time_win.cc causing problems (not the first time)

[Mike Belshe]

I think we should have a list of low-level functionality which we just never
cleanup.

For the items you listed, I think you should leak them all.  Trying to
cleanup these items creates complicated code and ultimately won't run any
better and possibly slower.

Mike



On Fri, Nov 20, 2009 at 1:44 PM, Paweł Hajdan Jr.
wrote:

> Do you have some idea how to get rid of the Singletons in base/time_win.cc?
> They don't play very well with base::SystemMonitor, MessageLoop, and test
> code.
>
> Here's the scenario we're hitting right now (in browser_tests):
>
> 1. HighResolutionTimerManager is created to enable high resolution timer
> unconditionally. An AtExit callback is created to destroy it.
> 2. The main MessageLoop is created. Its LazyInstance initializes a
> ThreadLocalPointer, which gets assigned the pointer to the MessageLoop. An
> AtExit callback is registered to reset the LazyInstance to the initial
> state.
> 3. BrowserMain enables monitoring SystemMonitor in
> HighResolutionTimerManager.
> 4. Which makes HighResolutionTimerManager register as a SystemMonitor
> observer.
>
> If everything seems OK so far, you're almost right. It's perfectly fine
> when browser runs, but has surprising "special effects" when test code runs.
> Here's what happens:
>
> 1. MessageLoop is destroyed. Its ThreadLocalPointer is set to NULL.
> 2. AtExit callbacks start to execute.
> 3. HighResolutionTimerManager is destroyed first. Its StopMonitoring method
> is called from dtor, which in turn touches MessageLoop::current(), which
> touches LazyInstance and makes it re-initialize itself, which registers
> AtExit callbacks which causes a DCHECK failure, because we're already
> processing AtExit callbacks.
>
> Don't worry too much if the explanation above is unclear (I'm afraid it
> is). The point is, it's not the first time that a nasty bug happens with
> SystemMonitor and the time_win.cc Singletons. Earlier it was different, so
> it's not so much important in what particular way it failed now.
>
> I'd really love to get rid of these Singletons. Do you have any ideas? We
> have two things here:
>
> 1) NowSingleton which keeps track of Windows time rollover. This might be
> harder to remove, but isn't causing too many problems.
> 2) HighResolutionTimerManager is causing problems. It was previously part
> of NowSingleton. I extracted the most evil part of it, and this is the
> current HRTM. I'm thinking about hardwiring it with the SystemMonitor or
> making it a Leaky Singleton maybe...
>
> --
> 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: Singleton shenanigans in base/time_win.cc causing problems (not the first time)

[cpu]

I hear you. The issue is to me endemic of singleton/lazyinstance

AtExit dtor -> Singleton A Object dtor --> Singleton B ctor -> AtExit
registration -> bang

Basically the dtors of singletons do too much or the whole scheme
stinks.



-- 
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] How can I remove .o objects in linux

[Evan Martin]

On Sun, Nov 22, 2009 at 1:43 PM, Antoine Labour  wrote:
> On Sun, Nov 22, 2009 at 1:35 PM, Adam Langley  wrote:
>>
>> On Sun, Nov 22, 2009 at 1:23 PM, hap 497  wrote:
>> > Can you please tell me how can I remove all .o after the build?
>> > I tried 'make clean', but it said there is no 'clean' target'.
>>
>> % find out -type f -name "*.o" | xargs rm
>
> Note that all .o go into the build directory, 'out', that you can simply
> wipe.

I would LGTM a gyp patch that aliases "make clean" to "rm -rf out".

-- 
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] How can I remove .o objects in linux

[Antoine Labour]

On Sun, Nov 22, 2009 at 1:35 PM, Adam Langley  wrote:

> On Sun, Nov 22, 2009 at 1:23 PM, hap 497  wrote:
> > Can you please tell me how can I remove all .o after the build?
> > I tried 'make clean', but it said there is no 'clean' target'.
>
> % find out -type f -name "*.o" | xargs rm
>

Note that all .o go into the build directory, 'out', that you can simply
wipe.

Antoine

-- 
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] How can I remove .o objects in linux

[Adam Langley]

On Sun, Nov 22, 2009 at 1:23 PM, hap 497  wrote:
> Can you please tell me how can I remove all .o after the build?
> I tried 'make clean', but it said there is no 'clean' target'.

% find out -type f -name "*.o" | xargs rm


AGL

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

[chromium-dev] How can I remove .o objects in linux

[hap 497]

Hi,

I follow this instruction in building chromium on linux.
http://code.google.com/p/chromium/wiki/LinuxBuildInstructions

Can you please tell me how can I remove all .o after the build?
I tried 'make clean', but it said there is no 'clean' target'.

Thank you.

-- 
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] whitlisting compilers for -Werror

[Antoine Labour]

On Sun, Nov 22, 2009 at 10:39 AM, Scott Hess  wrote:

> On Sat, Nov 21, 2009 at 2:08 PM, Antoine Labour  wrote:
> > So in practice, enabling -Werror for compilers we're not looking at has
> > about no positive effect for us, and a negative effect for
> users/potential
> > contributors, so I'll agree with Evan that we should only enable -Werror
> for
> > compilers we have a buildbot for (but for those, we should absolutely
> enable
> > it).
>
> Are there really so many cases where this comes up that a comment
> about how to turn off -Werror on
> http://code.google.com/p/chromium/wiki/LinuxBuildInstructions doesn't
> mostly solve it?
>

I added a blurb there. Still I think we should do the right thing by
default.

Antoine

-- 
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] How to compile Google Chrome with Visual C++ 2008 Express Edition

[PhistucK]

It keeps not working... :(

6>Linking...
6>libcpmt.lib(locale0.obj) : error LNK2005: "public: static unsigned int
const std::ctype::table_size" (?table_s...@?$ctype@d...@std@@2IB) already
defined in chrome_dll_main.obj
6>libcpmt.lib(locale.obj) : error LNK2005: "public: __thiscall
std::_Locinfo::~_Locinfo(void)" (??1_loci...@std@@q...@xz) already defined in
chrome_dll_main.obj
6>libcpmt.lib(locale.obj) : error LNK2005: "public: __thiscall
std::_Locinfo::_Locinfo(char const *)" (??0_loci...@std@@q...@pbd@Z) already
defined in chrome_dll_main.obj
6>libcpmt.lib(ios.obj) : error LNK2005: "public: virtual __thiscall
std::ios_base::~ios_base(void)" (??1ios_b...@std@@u...@xz) already defined in
chrome_dll_main.obj
6>libcpmt.lib(ios.obj) : error LNK2005: "public: void __thiscall
std::ios_base::clear(int,bool)" (?cl...@ios_base@std@@qaex...@z) already
defined in chrome_dll_main.obj
6>libcpmt.lib(ios.obj) : error LNK2005: "protected: void __thiscall
std::ios_base::_Init(void)" (?_i...@ios_base@std@@IAEXXZ) already defined in
chrome_dll_main.obj
6>LINK : fatal error LNK1104: cannot open file 'atlmincrt.lib'

☆PhistucK


On Sat, Nov 21, 2009 at 17:12, Dominic Jodoin wrote:

> Ok.
>
> First, I'm not sure if you should dynamically link with ATL because it
> works without on my PC.
>
> Second, can you look in VC++ 2005 Express under Tools > Options >
> Projects and Solutions > Show directories for: Library files and
> ensure you have added the ATL directory from the Windows Driver Kit
> there? Something like C:\WinDDK\6001.18002\lib\atl\i386 (may be
> different on you PC if you downloaded WDK 7).
>
> I looked back at my HOWTO and saw I did not include that step. Let me
> know if it works for you and I'll update it.
>
> Thanks!
>
> -- Dominic.
>
> On Tue, Nov 17, 2009 at 10:51 AM, PhistucK  wrote:
> > OK, so I am trying with Visual C++ 2005 Express. After working around
> most
> > of the errors, I got one (hopefully...) left -
> > fatal error LNK1104: cannot open file ‘atl.lib’ chrome_dll
> > The last error that I resolved before that, was almost the same, but
> “atlz”
> > instead of “atl” in the file name.
> > So I went to the chrome_dll properties and chose to dynamically link ATL
> and
> > it worked. But then I got the above error and I am at a loss.
> > Any ideas?
> > ☆PhistucK
> >
> >
> > On Tue, Nov 17, 2009 at 04:03, Marc-Antoine Ruel 
> wrote:
> >>
> >> Dominic, you should turn /WX off globally in src/build/common.gypi.
> >> That would simplify the patch.
> >>
> >> I guess the incremental link failure is due to the exe size on a 32
> >> bit OS, I'll mark it as a large binary so you can remove that step
> >> too.
> >>
> >> M-A
> >>
> >> On Mon, Nov 16, 2009 at 8:58 PM, Bradley Nelson 
> >> wrote:
> >> > That's good to hear!
> >> > I see you are mainly just turning off warnings as errors in a few
> spots.
> >> > Is this something that we can either gate in the build based on some
> >> > flag,
> >> > or are the warnings something that we could fix properly in the
> source?
> >> > I'd
> >> > love to peel off more steps from the process.
> >> > -BradN
> >> > On Mon, Nov 16, 2009 at 5:44 PM, Dominic Jodoin
> >> > 
> >> > wrote:
> >> >>
> >> >> Hey Brad!
> >> >>
> >> >> I just wanted to let you know that this is working great for me on
> >> >> VC++ 2008 Express Edition. Thanks a lot!
> >> >>
> >> >> I have updated my page to reflect your change. I also added a patch
> >> >> that modifies some GYP files in such a way that you won’t have to
> >> >> manually “play” with the project settings in order to compile without
> >> >> errors (with this compiler that is).
> >> >>
> >> >>
> >> >>
> >> >>
> http://cotsog.wordpress.com/2009/11/08/how-to-compile-google-chrome-with-visual-c-2008-express-edition/
> >> >>
> >> >> -- Dominic.
> >> >>
> >> >> On Thu, Nov 12, 2009 at 7:51 PM, Bradley Nelson <
> bradnel...@google.com>
> >> >> wrote:
> >> >> > Ok that fix is in.
> >> >> > You'd need to set GYP_MSVS_VERSION=2008e
> >> >> > Let me know how that goes for you.
> >> >> > -BradN
> >> >> >
> >> >> > On Wed, Nov 11, 2009 at 12:50 PM, Marc-Antoine Ruel
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> Updated
> >> >> >>
> >> >> >>
> >> >> >>
> http://sites.google.com/a/chromium.org/dev/developers/how-tos/build-instructions-windows
> >> >> >> to reference your blog entry.
> >> >> >>
> >> >> >> I don't want to copy these instructions since it's too lengthy,
> >> >> >> inefficient and unsupported.
> >> >> >>
> >> >> >> I didn't realize one could download WDK 7 without needing a MSDN
> >> >> >> account. That's cool.
> >> >> >>
> >> >> >> M-A
> >> >> >>
> >> >> >> On Tue, Nov 10, 2009 at 10:39 PM, Dominic Jodoin
> >> >> >>  wrote:
> >> >> >> > On Tue, Nov 10, 2009 at 10:25 PM, Peter Kasting
> >> >> >> > 
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> What do you mean?  Or to be more precise, what would
> considering
> >> >> >> >> your
> >> >> >> >> steps
> >> >> >> >> "a valid setup to contribute" concretely result in?
> >> >> >> >> PK
> >> 

Re: [chromium-dev] How to compile Google Chrome with Visual C++ 2008 Express Edition

[PhistucK]

It is probably that. I have not tried yet, but I will this afternoon.
It must have been an obvious thing to do, but I am not dealing with Visual
Studio almost at all and I am totally new to this, so, thank you for
pointing that out. :)

☆PhistucK


On Sat, Nov 21, 2009 at 17:12, Dominic Jodoin wrote:

> Ok.
>
> First, I'm not sure if you should dynamically link with ATL because it
> works without on my PC.
>
> Second, can you look in VC++ 2005 Express under Tools > Options >
> Projects and Solutions > Show directories for: Library files and
> ensure you have added the ATL directory from the Windows Driver Kit
> there? Something like C:\WinDDK\6001.18002\lib\atl\i386 (may be
> different on you PC if you downloaded WDK 7).
>
> I looked back at my HOWTO and saw I did not include that step. Let me
> know if it works for you and I'll update it.
>
> Thanks!
>
> -- Dominic.
>
> On Tue, Nov 17, 2009 at 10:51 AM, PhistucK  wrote:
> > OK, so I am trying with Visual C++ 2005 Express. After working around
> most
> > of the errors, I got one (hopefully...) left -
> > fatal error LNK1104: cannot open file ‘atl.lib’ chrome_dll
> > The last error that I resolved before that, was almost the same, but
> “atlz”
> > instead of “atl” in the file name.
> > So I went to the chrome_dll properties and chose to dynamically link ATL
> and
> > it worked. But then I got the above error and I am at a loss.
> > Any ideas?
> > ☆PhistucK
> >
> >
> > On Tue, Nov 17, 2009 at 04:03, Marc-Antoine Ruel 
> wrote:
> >>
> >> Dominic, you should turn /WX off globally in src/build/common.gypi.
> >> That would simplify the patch.
> >>
> >> I guess the incremental link failure is due to the exe size on a 32
> >> bit OS, I'll mark it as a large binary so you can remove that step
> >> too.
> >>
> >> M-A
> >>
> >> On Mon, Nov 16, 2009 at 8:58 PM, Bradley Nelson 
> >> wrote:
> >> > That's good to hear!
> >> > I see you are mainly just turning off warnings as errors in a few
> spots.
> >> > Is this something that we can either gate in the build based on some
> >> > flag,
> >> > or are the warnings something that we could fix properly in the
> source?
> >> > I'd
> >> > love to peel off more steps from the process.
> >> > -BradN
> >> > On Mon, Nov 16, 2009 at 5:44 PM, Dominic Jodoin
> >> > 
> >> > wrote:
> >> >>
> >> >> Hey Brad!
> >> >>
> >> >> I just wanted to let you know that this is working great for me on
> >> >> VC++ 2008 Express Edition. Thanks a lot!
> >> >>
> >> >> I have updated my page to reflect your change. I also added a patch
> >> >> that modifies some GYP files in such a way that you won’t have to
> >> >> manually “play” with the project settings in order to compile without
> >> >> errors (with this compiler that is).
> >> >>
> >> >>
> >> >>
> >> >>
> http://cotsog.wordpress.com/2009/11/08/how-to-compile-google-chrome-with-visual-c-2008-express-edition/
> >> >>
> >> >> -- Dominic.
> >> >>
> >> >> On Thu, Nov 12, 2009 at 7:51 PM, Bradley Nelson <
> bradnel...@google.com>
> >> >> wrote:
> >> >> > Ok that fix is in.
> >> >> > You'd need to set GYP_MSVS_VERSION=2008e
> >> >> > Let me know how that goes for you.
> >> >> > -BradN
> >> >> >
> >> >> > On Wed, Nov 11, 2009 at 12:50 PM, Marc-Antoine Ruel
> >> >> > 
> >> >> > wrote:
> >> >> >>
> >> >> >> Updated
> >> >> >>
> >> >> >>
> >> >> >>
> http://sites.google.com/a/chromium.org/dev/developers/how-tos/build-instructions-windows
> >> >> >> to reference your blog entry.
> >> >> >>
> >> >> >> I don't want to copy these instructions since it's too lengthy,
> >> >> >> inefficient and unsupported.
> >> >> >>
> >> >> >> I didn't realize one could download WDK 7 without needing a MSDN
> >> >> >> account. That's cool.
> >> >> >>
> >> >> >> M-A
> >> >> >>
> >> >> >> On Tue, Nov 10, 2009 at 10:39 PM, Dominic Jodoin
> >> >> >>  wrote:
> >> >> >> > On Tue, Nov 10, 2009 at 10:25 PM, Peter Kasting
> >> >> >> > 
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> What do you mean?  Or to be more precise, what would
> considering
> >> >> >> >> your
> >> >> >> >> steps
> >> >> >> >> "a valid setup to contribute" concretely result in?
> >> >> >> >> PK
> >> >> >> >
> >> >> >> > I'm wondering if using a hacked ATL version 7.1 could lead to
> bugs
> >> >> >> > given the product is built, I suppose, with ATL coming with
> Visual
> >> >> >> > Studio 2005 or 2008 which is a different version.
> >> >> >> >
> >> >> >> > But what I meant was that if the steps were to be approved, I
> >> >> >> > thought
> >> >> >> > they could be included on http://dev.chromium.org.
> >> >> >> >
> >> >> >> > -- Dominic.
> >> >> >> >
> >> >> >> > --
> >> >> >> > 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://gr