Duplicate OT name table parsing symbols in Chromium build

[drott]

In doing a larger HarfBuzz roll in Chromium, I get a duplicate symbol linking failure, and a conflict between symbols built from hb-subset.cc and hb-ot-name.cc. I don't have an immediate fix suggestions, I assume these may need to be moved to a source file and built separately, instead of the header includes?

Error:

ld.lld: error: duplicate symbol: _hb_ot_name_language_for_ms_code(unsigned int)
>>> defined at hb-ot-name.cc
>>>            obj/third_party/harfbuzz-ng/harfbuzz_source/hb-ot-name.o:(_hb_ot_name_language_for_ms_code(unsigned int))
>>> defined at hb-subset.cc
>>>            obj/third_party/harfbuzz-ng/harfbuzz_source/hb-subset.o:(.text+0x0)

ld.lld: error: duplicate symbol: _hb_ot_name_language_for_mac_code(unsigned int)
>>> defined at hb-ot-name.cc
>>>            obj/third_party/harfbuzz-ng/harfbuzz_source/hb-ot-name.o:(_hb_ot_name_language_for_mac_code(unsigned int))
>>> defined at hb-subset.cc
>>>            obj/third_party/harfbuzz-ng/harfbuzz_source/hb-subset.o:(.text+0x0)

I experimentally reverted the change that moved the name table logic to OT/name/name.hh f89fa6d - but that, as mostly expected, did not change anything.

[drott]

CC @matthiasclasen

[behdad]

I wonder why we don't get this in our builds though.

[behdad]

cc @qxliu76

[behdad]

I wonder why we don't get this in our builds though.

That's because we compile these two files into separate libraries.

[behdad]

The solution is to move _hb_ot_name_language_for_ms_code into hb-static.cc again. I think it used to be there.

[behdad]

I believe this is the commit that broke this: 7b5f0dd