adjust output dir for msvs to fix msvs link error

adjust output dir for msvs to fix msvs link error

BUG=msvs build
R=jam@chromium.org

Committed: https://pdfium.googlesource.com/pdfium/+/9ea3da2

[Bo Xu, 2014-05-25 05:33:57]

Hi,John, please help to review this issue

[jam, 2014-05-25 15:28:55]

On 2014/05/25 05:33:57, bo_xu wrote:
> Hi,John, please help to review this issue

Hi Bo, I'm able to link pdfium_test fine without this. What configuration do you
see this problem with? i.e. when building inside a Chromium checkout, or in  a
standalone checkout? If standalone, can you share your build errors on pastebin?
And to confirm, you followed the pdfium build wiki
https://code.google.com/p/pdfium/wiki/Build?

[Bo Xu, 2014-05-25 18:20:44]

On 2014/05/25 15:28:55, jam wrote:
> On 2014/05/25 05:33:57, bo_xu wrote:
> > Hi,John, please help to review this issue
> 
> Hi Bo, I'm able to link pdfium_test fine without this. What configuration do
you
> see this problem with? i.e. when building inside a Chromium checkout, or in  a
> standalone checkout? If standalone, can you share your build errors on
pastebin?
> And to confirm, you followed the pdfium build wiki
> https://code.google.com/p/pdfium/wiki/Build

Hi John,

In standalone build, using old configuration, icu related dll like icui18n.dll
will be generated in ~/pdfium/out directory and mksnapshot.exe will be generated
in ~/pdfium/build folder. Building v8_snapshot needs to run mksnapshot.exe which
requires icui18n.dll and it will fail (Error 20 below), so v8_snapshot and v8
will not build. The errors are:

Error	20	error MSB6006: "cmd.exe" exited with code 53.	

Error	21	error LNK1181: cannot open input file
'C:\Projects\google\stand-alone-build\pdfium\build\Release\lib\v8_snapshot.lib'	C:\Projects\google\stand-alone-build\pdfium\v8\tools\gyp\LINK

Error	111	error LNK1181: cannot open input file
'C:\Projects\google\stand-alone-build\pdfium\build\Release\v8.lib'	C:\Projects\google\stand-alone-build\pdfium\samples\LINK

[jam, 2014-05-27 01:10:37]

Hi Bo, ok I looked into this and I believe the problem was caused by my moving
of the linker dependencies from standalone.gypi (which applied to v8 and icu's
gyp) to pdfium.gyp (which didn't). I'm not sure exactly why this didn't repro
for me before, it might be because another bug somewhere only exposes this for
clean builds and not incremental.

I have a fix in https://codereview.chromium.org/297293005/ and
https://codereview.chromium.org/299353008/

[jam, 2014-05-27 01:32:18]

On 2014/05/27 01:10:37, jam wrote:
> Hi Bo, ok I looked into this and I believe the problem was caused by my moving
> of the linker dependencies from standalone.gypi (which applied to v8 and icu's
> gyp) to pdfium.gyp (which didn't). I'm not sure exactly why this didn't repro
> for me before, it might be because another bug somewhere only exposes this for
> clean builds and not incremental.
> 
> I have a fix in https://codereview.chromium.org/297293005/ and
> https://codereview.chromium.org/299353008/

btw these changes landed now, so please let me know if you have problems after
updating icu (svn update v8/third_party/icu) and pdfium (git pull) and then
rerunning gyp (build/gyp_pdfium). Thanks.

[Bo Xu, 2014-05-27 02:59:56]

> btw these changes landed now, so please let me know if you have problems after
> updating icu (svn update v8/third_party/icu) and pdfium (git pull) and then
> rerunning gyp (build/gyp_pdfium). Thanks.

I just tried it but still sees the error and a linking issue with icuuc

6>     Creating library ..\..\..\out\Debug\icuuc.lib and object
..\..\..\out\Debug\icuuc.exp
6>umapfile.obj : error LNK2019: unresolved external symbol
__imp__SetSecurityDescriptorDacl@16 referenced in function _uprv_mapFile_46
6>umapfile.obj : error LNK2019: unresolved external symbol
__imp__InitializeSecurityDescriptor@8 referenced in function _uprv_mapFile_46
6>wintz.obj : error LNK2019: unresolved external symbol __imp__RegCloseKey@4
referenced in function _getTZI
6>wintz.obj : error LNK2019: unresolved external symbol
__imp__RegQueryValueExA@24 referenced in function _getTZI
6>wintz.obj : error LNK2019: unresolved external symbol __imp__RegOpenKeyExA@20
referenced in function _openTZRegKey
6>..\..\..\out\Debug\icuuc.dll : fatal error LNK1120: 5 unresolved externals

It seems to me the multiple output directory (pdfium/out and pdfium/build) is
the root cause of the issue and this multiple output directory is not like what
I see in chromium. Do you think fixing it as this patch would work?

[jam, 2014-05-27 04:49:10]

On 2014/05/27 02:59:56, bo_xu wrote:
> > btw these changes landed now, so please let me know if you have problems
after
> > updating icu (svn update v8/third_party/icu) and pdfium (git pull) and then
> > rerunning gyp (build/gyp_pdfium). Thanks.
> 
> I just tried it but still sees the error and a linking issue with icuuc
> 
> 6>     Creating library ..\..\..\out\Debug\icuuc.lib and object
> ..\..\..\out\Debug\icuuc.exp
> 6>umapfile.obj : error LNK2019: unresolved external symbol
> __imp__SetSecurityDescriptorDacl@16 referenced in function _uprv_mapFile_46
> 6>umapfile.obj : error LNK2019: unresolved external symbol
> __imp__InitializeSecurityDescriptor@8 referenced in function _uprv_mapFile_46
> 6>wintz.obj : error LNK2019: unresolved external symbol __imp__RegCloseKey@4
> referenced in function _getTZI
> 6>wintz.obj : error LNK2019: unresolved external symbol
> __imp__RegQueryValueExA@24 referenced in function _getTZI
> 6>wintz.obj : error LNK2019: unresolved external symbol
__imp__RegOpenKeyExA@20
> referenced in function _openTZRegKey
> 6>..\..\..\out\Debug\icuuc.dll : fatal error LNK1120: 5 unresolved externals
> 
> It seems to me the multiple output directory (pdfium/out and pdfium/build) is
> the root cause of the issue and this multiple output directory is not like
what
> I see in chromium. Do you think fixing it as this patch would work?

this problem you're seeing is the same one i saw. are you sure you synced icu?
if you do "svn info v8/third_party/icu" what do you see? Did you run
"build/gyp_pdfium"? I tried visual studio clean build and it works fine for me.

[Bo Xu, 2014-05-27 05:22:41]

> this problem you're seeing is the same one i saw. are you sure you synced icu?
> if you do "svn info v8/third_party/icu" what do you see? Did you run
> "build/gyp_pdfium"? I tried visual studio clean build and it works fine for
me.

I did run svn up on icu and build/gyp_pdfium. This is what I saw in svn info
v8/third_party/icu

$ svn info v8/third_party/icu
Path: v8/third_party/icu
Working Copy Root Path:
/cygdrive/c/Projects/google/stand-alone-build/pdfium/v8/third_party/icu
URL: https://src.chromium.org/chrome/trunk/deps/third_party/icu46
Relative URL: ^/trunk/deps/third_party/icu46
Repository Root: https://src.chromium.org/chrome
Repository UUID: 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Revision: 272911
Node Kind: directory
Schedule: normal
Last Changed Author: jam@chromium.org
Last Changed Rev: 272908
Last Changed Date: 2014-05-26 18:25:03 -0700 (Mon, 26 May 2014)

[Bo Xu, 2014-05-27 05:25:08]

Besides clean, can you try remove the whole out folder and
pdfium/build/Debug(Release). Maybe the .dll and .lib from ninja build is in
there, so it builds fine?

[jam, 2014-05-27 15:09:58]

On 2014/05/27 05:22:41, bo_xu wrote:
> > this problem you're seeing is the same one i saw. are you sure you synced
icu?
> > if you do "svn info v8/third_party/icu" what do you see? Did you run
> > "build/gyp_pdfium"? I tried visual studio clean build and it works fine for
> me.
> 
> I did run svn up on icu and build/gyp_pdfium. This is what I saw in svn info
> v8/third_party/icu
> 
> $ svn info v8/third_party/icu
> Path: v8/third_party/icu
> Working Copy Root Path:
> /cygdrive/c/Projects/google/stand-alone-build/pdfium/v8/third_party/icu
> URL: https://src.chromium.org/chrome/trunk/deps/third_party/icu46
> Relative URL: ^/trunk/deps/third_party/icu46
> Repository Root: https://src.chromium.org/chrome
> Repository UUID: 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
> Revision: 272911
> Node Kind: directory
> Schedule: normal
> Last Changed Author: mailto:jam@chromium.org
> Last Changed Rev: 272908
> Last Changed Date: 2014-05-26 18:25:03 -0700 (Mon, 26 May 2014)

On 2014/05/27 05:25:08, bo_xu wrote:
> Besides clean, can you try remove the whole out folder and
> pdfium/build/Debug(Release). Maybe the .dll and .lib from ninja build is in
> there, so it builds fine?

Yep I had done that before. Did you do this as well? Also, make sure that
running "build\gyp_pdfium" is done while the visual studio solution is not open.
Sometimes that interferes with the writing of the files.

What about the ninja build, does that work for you?

[Bo Xu, 2014-05-27 17:35:35]

> On 2014/05/27 05:25:08, bo_xu wrote:
> > Besides clean, can you try remove the whole out folder and
> > pdfium/build/Debug(Release). Maybe the .dll and .lib from ninja build is in
> > there, so it builds fine?
> 
> Yep I had done that before. Did you do this as well? Also, make sure that
> running "build\gyp_pdfium" is done while the visual studio solution is not
open.
> Sometimes that interferes with the writing of the files.
> 
> What about the ninja build, does that work for you?

I just did a brand new checkout of standalone pdfium on another computer. I did
see the the above link error.

Ninja works fine here.

[jam, 2014-05-27 22:43:05]

On 2014/05/27 17:35:35, bo_xu wrote:
> > On 2014/05/27 05:25:08, bo_xu wrote:
> > > Besides clean, can you try remove the whole out folder and
> > > pdfium/build/Debug(Release). Maybe the .dll and .lib from ninja build is
in
> > > there, so it builds fine?
> > 
> > Yep I had done that before. Did you do this as well? Also, make sure that
> > running "build\gyp_pdfium" is done while the visual studio solution is not
> open.
> > Sometimes that interferes with the writing of the files.
> > 
> > What about the ninja build, does that work for you?
> 
> I just did a brand new checkout of standalone pdfium on another computer. I
did
> see the the above link error.
> 
> Ninja works fine here.

hmm, so I followed the instructions from the wiki for a new checkout and it also
worked. I even also tried VS2010, VS2012, and VS2013 and all three worked.
However a colleague's computer failed like yours. I can't figure out the
difference; so lgtm to land this cl. Thanks for your patience.

[Bo Xu, 2014-05-27 23:03:55]

Committed patchset #1 manually as r9ea3da2 (presubmit successful).