Move stubdata.c from icudata to icuuc

Move stubdata.c from icudata to icuuc

This is to fix a linker error when linking icuuc.dll;  ICU_DATA_ENTRY (icudt54_dat) symbol is not found on Windows clean build from the scratch (component=shared_library).

Move stubdata.c to icuuc target from icudata target. Also, make
U_DATA_API (used for U_ICU_DATA_ENTRYPOINT in common/udata.cpp) to be
U_EXPORT instead of U_IMPORT when icu_use_data_file_flag = 1 or
on Windows. On Windows, using the icudt.dll  (i.e. icu_use_data_file_flag=0) also requires this change.

BUG=428145
TEST=All trybots can build a target that requires ICU.
R=mark@chromium.org, scottmg@chromium.org

Committed: https://chromium.googlesource.com/chromium/deps/icu/+/d158fece3ebecaef3a68a8a98f3cec6672ffd11e

[jungshik at Google, 2015-02-13 21:31:43]

The error in question from some (NOT all) windows bots is :

FAILED: E:\b\depot_tools\python276_bin\python.exe gyp-win-tool
link-with-manifests environment.x86 True icuuc.dll
"E:\b\depot_tools\python276_bin\python.exe gyp-win-tool link-wrapper
environment.x86 False link.exe /nologo /IMPLIB:icuuc.dll.lib /DLL /OUT:icuuc.dll
@icuuc.dll.rsp" 2 mt.exe rc.exe
"obj\third_party\icu\icuuc.icuuc.dll.intermediate.manifest"
obj\third_party\icu\icuuc.icuuc.dll.generated.manifest
LINK : icuuc.dll not found or not built by the last incremental link; performing
full link

icuuc.udata.obj : error LNK2019: unresolved external symbol __imp__icudt54_dat
referenced in function "struct UDataMemory * __cdecl openCommonData(char const
*,int,enum UErrorCode *)"
(?openCommonData@@YAPAUUDataMemory@@PBDHPAW4UErrorCode@@@Z)

icuuc.dll : fatal error LNK1120: 1 unresolved externals

[jungshik at Google, 2015-02-13 23:27:40]

jshin@chromium.org changed reviewers:
+ mark@chromium.org, scottmg@chromium.org

[jungshik at Google, 2015-02-13 23:38:54]

Scott and Mark, can you take a look? 

I was able to reproduce this issue (a linker error) on Windows and confirmed
that this CL fixed the issue. 

Just to make sure, I tried {shared, static} builds on {linux, mac} in addition
to shared_library build on Windows (each time from the scratch) and all got
built fine. As a sanity check, I also ran base_unittests and it's fine, too. [1]

The reason we didn't have this linker error in 52.1 is that we changed
U_DATA_API to be U_EXPORT instead of U_IMPORT for COMMON_IMPLEMENTATION for a
totally different reason. We dropped that patch and bumped into this issue. 

This patch is more 'logical' than the one we used to have in 4.6.1/52.1. 

[1] Although static_library build is not affected by this change, I'm building a
static_lib build on Windows no.

[Mark Mentovai, 2015-02-13 23:45:22]

LGTM

[scottmg, 2015-02-13 23:46:32]

It seems like only Android Webview doesn't use the data file now? Could we
remove the "win" condition here? I guess confirm that an android build works,
too, if you didn't already.

Is there a corresponding GN change required?

[Mark Mentovai, 2015-02-13 23:48:09]

Pretty sure the gn build description is in the Chrome repository, while the gyp
one is in our one for icu.

[jungshik at Google, 2015-02-13 23:52:31]

On 2015/02/13 23:48:09, Mark Mentovai wrote:
> Pretty sure the gn build description is in the Chrome repository, while the
gyp
> one is in our one for icu.

Yes, the GN build description is in the chrome repo. So, I have to fix it as a
part of https://codereview.chromium.org/878723002/

[jungshik at Google, 2015-02-13 23:58:26]

On 2015/02/13 23:46:32, scottmg wrote:
> It seems like only Android Webview doesn't use the data file now? Could we
> remove the "win" condition here? 

win condition is there for a non-default windows build option (icu..data_flag=0)
that uses icudt.dll. However, it's deprecated. Perpahs, we have to remove that
option completely on Windows. Can I do it in after completing the ICU upgrade to
54.1?  

> I guess confirm that an android build works, too, if you didn't already.


I haven't checked android build, yet. I'm planning to rely on trybot after
landing this CL. :-)
 Webview build (because this CL does not affect when icu_use_data_file_flag=0 on
Android) should be all right.  


> Is there a corresponding GN change required?

[scottmg, 2015-02-14 00:01:56]

OK, thanks. lgtm.

[jungshik at Google, 2015-02-14 00:02:10]

On 2015/02/13 23:52:31, Jungshik at google wrote:
> On 2015/02/13 23:48:09, Mark Mentovai wrote:
> > Pretty sure the gn build description is in the Chrome repository, while the
> gyp
> > one is in our one for icu.
> 
> Yes, the GN build description is in the chrome repo. So, I have to fix it as a
> part of https://codereview.chromium.org/878723002/

It turned out that GN build description exactly does what's done here.  See
https://code.google.com/p/chromium/codesearch#chromium/src/build/secondary/th...

  if (is_win || icu_use_data_file) {
    sources += [ "source/stubdata/stubdata.c" ]

[scottmg, 2015-02-14 00:02:28]

On 2015/02/13 23:58:26, Jungshik at google wrote:
> On 2015/02/13 23:46:32, scottmg wrote:
> > It seems like only Android Webview doesn't use the data file now? Could we
> > remove the "win" condition here? 
> 
> win condition is there for a non-default windows build option
(icu..data_flag=0)
> that uses icudt.dll. However, it's deprecated. Perpahs, we have to remove that
> option completely on Windows. Can I do it in after completing the ICU upgrade
to
> 54.1?  

(yes, not urgent, I was more asking so I knew what was going on.)

> 
> > I guess confirm that an android build works, too, if you didn't already.
> 
> 
> I haven't checked android build, yet. I'm planning to rely on trybot after
> landing this CL. :-)
>  Webview build (because this CL does not affect when icu_use_data_file_flag=0
on
> Android) should be all right.  
> 
> 
> > Is there a corresponding GN change required?

[jungshik at Google, 2015-02-14 00:28:24]

Committed patchset #1 (id:1) manually as
d158fece3ebecaef3a68a8a98f3cec6672ffd11e (presubmit successful).

[jungshik at Google, 2015-02-14 15:16:56]

https://codereview.chromium.org/926113004/diff/1/icu.gyp
File icu.gyp (right):

https://codereview.chromium.org/926113004/diff/1/icu.gyp#newcode138
icu.gyp:138: 'sources/': [['exclude', 'icudtl_dat']],
To prevent libicudata.a or its Win-equivalent (that will not be generated any
more) from being looked for by a linker, I'll make another CL to add 'type:
none' to this section. Somehow it was not a problem in my local tests
(Win,Mac/Linux) nor in most trybots (except for one ios bot).