MSVC 2010 Express Status

[Ryan Norton]

Just letting people know that MSVC 2010 has compiled Chromium mostly
cleanly for a while now for me with a couple tweaks:

1) http://codereview.chromium.org/6729005/ - Adds support for
GYP_MSVS_VERSION=2010e and turns on flat solution generation for the
express version similar to other versions of MSVC vs. normal versions.

I've had this patch sitting on my local copy for about 2 weeks
already. I think the GYP people are overworked or something and I
should probably split it up a bit.

Somewhat OT: In terms of autodetection, there's a problem with GYP
using the 32-bit version of reg.exe on 64-bit machines with the
default depot_tools due to the 32-bit version of python.

However, there's a workaround for this. You can use Windows\sysnative
to avoid being redirected to Windows\SysWOW64 from Windows\System32 in
32-bit processes. Works for vista and above, and there's a hotfix for
as low as even 64-bit XP for this (http://support.microsoft.com/kb/
942589/en-us).

2) Link errors on npchrome_frame due to multiple definitions:
----------
1>nspr.lib(prinit.obj) : error LNK2005: _PR_CallOnce already defined
in nspr4.lib(nspr4.dll)
1>nspr.lib(prinit.obj) : error LNK2005: _PR_CallOnceWithArg already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prnetdb.obj) : error LNK2005: _PR_ConvertIPv4AddrToIPv6
already defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prnetdb.obj) : error LNK2005: _PR_htonll already defined in
nspr4.lib(nspr4.dll)
1>nspr.lib(prnetdb.obj) : error LNK2005: _PR_StringToNetAddr already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prerror.obj) : error LNK2005: _PR_GetError already defined
in nspr4.lib(nspr4.dll)
1>nspr.lib(prerror.obj) : error LNK2005: _PR_SetError already defined
in nspr4.lib(nspr4.dll)
1>nspr.lib(prprf.obj) : error LNK2005: _PR_smprintf_free already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prprf.obj) : error LNK2005: _PR_smprintf already defined in
nspr4.lib(nspr4.dll)
1>nspr.lib(priometh.obj) : error LNK2005: _PR_Close already defined in
nspr4.lib(nspr4.dll)
1>nspr.lib(priometh.obj) : error LNK2005: _PR_Read already defined in
nspr4.lib(nspr4.dll)
1>nspr.lib(priometh.obj) : error LNK2005: _PR_Write already defined in
nspr4.lib(nspr4.dll)
1>nspr.lib(priometh.obj) : error LNK2005: _PR_GetSocketOption already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(priometh.obj) : error LNK2005: _PR_EmulateAcceptRead
already defined in nspr4.lib(nspr4.dll)
1>nspr.lib(priometh.obj) : error LNK2005: _PR_EmulateSendFile already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prlog.obj) : error LNK2005: _PR_Assert already defined in
nspr4.lib(nspr4.dll)
1>nspr.lib(prlayer.obj) : error LNK2005: _PR_GetDefaultIOMethods
already defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prlayer.obj) : error LNK2005: _PR_CreateIOLayerStub already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prlayer.obj) : error LNK2005: _PR_GetUniqueIdentity already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prlayer.obj) : error LNK2005: _PR_GetIdentitiesLayer
already defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prlayer.obj) : error LNK2005: _PR_PushIOLayer already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prlayer.obj) : error LNK2005: _PR_PopIOLayer already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prulock.obj) : error LNK2005: _PR_NewLock already defined
in nspr4.lib(nspr4.dll)
1>nspr.lib(prulock.obj) : error LNK2005: _PR_DestroyLock already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prulock.obj) : error LNK2005: _PR_Lock already defined in
nspr4.lib(nspr4.dll)
1>nspr.lib(prulock.obj) : error LNK2005: _PR_Unlock already defined in
nspr4.lib(nspr4.dll)
1>nspr.lib(prcthr.obj) : error LNK2005: _PR_GetCurrentThread already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prcthr.obj) : error LNK2005: _PR_Sleep already defined in
nspr4.lib(nspr4.dll)
1>nspr.lib(prmmap.obj) : error LNK2005: _PR_MemMap already defined in
nspr4.lib(nspr4.dll)
1>nspr.lib(prmmap.obj) : error LNK2005: _PR_MemUnmap already defined
in nspr4.lib(nspr4.dll)
1>nspr.lib(prmmap.obj) : error LNK2005: _PR_CloseFileMap already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prmon.obj) : error LNK2005: _PR_NewMonitor already defined
in nspr4.lib(nspr4.dll)
1>nspr.lib(prmon.obj) : error LNK2005: _PR_DestroyMonitor already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prmon.obj) : error LNK2005: _PR_EnterMonitor already
defined in nspr4.lib(nspr4.dll)
1>nspr.lib(prmon.obj) : error LNK2005: _PR_ExitMonitor already defined
in nspr4.lib(nspr4.dll)
------------

This can be "solved" by removing '../third_party/xulrunner-sdk/win/
lib/nspr4.lib'; it is probably indicative of some real build clashes
due to a source file being included twice; I've tried tracking it down
but the 2010 is rather complex with it's property pages and such.
Rather then doing it manually each runhooks, you can do this hack:
-------------------
Index: D:/chromiumtrunk10/src/chrome_frame/chrome_frame.gyp
===================================================================
--- D:/chromiumtrunk10/src/chrome_frame/chrome_frame.gyp (revision
80536)
+++ D:/chromiumtrunk10/src/chrome_frame/chrome_frame.gyp (working
copy)
@@ -988,6 +988,13 @@
'-lshdocvw.lib',
],
},
+ 'conditions': [
+ ['MSVS_VERSION=="2010e"', {
+ 'libraries!': [
+ '../third_party/xulrunner-sdk/win/lib/nspr4.lib',
+ ],
+ }],
+ ],
'msvs_settings': {
'VCLinkerTool': {
'OutputFile':
--------------------

In terms of functionality it seems fine and all expected unit tests
appear to pass.

As for SP1 - it doesn't appear to make a difference either way, though
it did screw up my property sheet configuration and force me to turn
of TrackingEnabled in my main property sheet (don't ask, 2010's
building system is like a datastructure from hell, and when there is a
error from Tracker.exe it basically _never_ tells you what the real
problem is).

[Tommi]

Could the linker problem be solved the other way and instead of changing

chrome frame, change whatever is depending on the other lib?

Afaik CF is depending on the "proper" nspr4 lib and the other lib is a hacked

up version of nspr4.

It feels like changing something to depend on the hacked lib rather than

going the other way isn't right.  However I don't know all the details so maybe

there is a good reason for doing so?

Tommi

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

[Tommi]

Just to follow up on this - I'm removing all nspr4 dependency from Chrome Frame so that should clear up this problem.

[Ryan Norton]

Just confirming it compiles cleanly without a gyp file hack now -
thanks a ton! Just the GYP-side CR (#1) left.

On Apr 7, 2:45 pm, Tommi <to...@chromium.org> wrote:
> Just to follow up on this - I'm removing all nspr4 dependency from Chrome
> Frame so that should clear up this problem.
>
>
>
> On Wed, Apr 6, 2011 at 5:20 PM, Tommi <to...@chromium.org> wrote:
> > Could the linker problem be solved the other way and instead of changing
> > chrome frame, change whatever is depending on the other lib?
>
> > Afaik CF is depending on the "proper" nspr4 lib and the other lib is a
> > hacked
> > up version of nspr4.
>
> > It feels like changing something to depend on the hacked lib rather than
> > going the other way isn't right.  However I don't know all the details so
> > maybe
> > there is a good reason for doing so?
>
> > Tommi
>

> > On Wed, Apr 6, 2011 at 5:05 PM, Ryan Norton <rnorto...@gmail.com> wrote:
>
> >> Just letting people know that MSVC 2010 has compiled Chromium mostly
> >> cleanly for a while now for me with a couple tweaks:
>

> >> 1)http://codereview.chromium.org/6729005/- Adds support for

> >> GYP_MSVS_VERSION=2010e and turns on flat solution generation for the
> >> express version similar to other versions of MSVC vs. normal versions.
>
> >> I've had this patch sitting on my local copy for about 2 weeks
> >> already. I think the GYP people are overworked or something and I
> >> should probably split it up a bit.
>
> >> Somewhat OT: In terms of autodetection, there's a problem with GYP
> >> using the 32-bit version of reg.exe on 64-bit machines with the
> >> default depot_tools due to the 32-bit version of python.
>
> >> However, there's a workaround for this. You can use Windows\sysnative
> >> to avoid being redirected to Windows\SysWOW64 from Windows\System32 in
> >> 32-bit processes. Works for vista and above, and there's a hotfix for
> >> as low as even 64-bit XP for this (http://support.microsoft.com/kb/

> >> 942589/en-us <http://support.microsoft.com/kb/942589/en-us>).

> >> Chromium Developers mailing list: chromium-...@chromium.org