1583332 - Fix huge clang-cl link warning: lld-link: warning: ..\..\..\extensions\spellcheck\hunspell\glue\Unified_cpp_hunspell_glue0.obj

Status: RESOLVED FIXED

(Core :: Spelling checker, defect)

Description

[Jorg K (CEST = GMT+2)]

I've been seeing this form months now hoping that someone else would complain and fix it, but no such luck.

Since the spelling checker is mostly "unowned", perhaps some of the people dealing with the compilers could take a look.

No offence intended by NI'in the wrong people ;-)

0:16.33 lld-link: warning: ......\extensions\spellcheck\hunspell\glue\Unified_cpp_hunspell_glue0.obj: locally defined symbol imported: "public: __cdecl Hunspell::~Hunspell(void)" (??1Hunspell@@QEAA@XZ) (defined in ......\extensions\spellcheck\hunspell\src\Unified_cpp_hunspell_src0.obj) [LNK4217]
0:16.33 lld-link: warning: ......\extensions\spellcheck\hunspell\glue\Unified_cpp_hunspell_glue0.obj: locally defined symbol imported: "public: __cdecl Hunspell::Hunspell(char const *, char const *, char const *)" (??0Hunspell@@QEAA@PEBD00@Z) (defined in ......\extensions\spellcheck\hunspell\src\Unified_cpp_hunspell_src0.obj) [LNK4217]
0:16.33 lld-link: warning: ......\extensions\spellcheck\hunspell\glue\Unified_cpp_hunspell_glue0.obj: locally defined symbol imported: "public: class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>> const & __cdecl Hunspell::get_dict_encoding(void) const" (?get_dict_encoding@Hunspell@@QEBAAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ) (defined in ......\extensions\spellcheck\hunspell\src\Unified_cpp_hunspell_src0.obj) [LNK4217]
0:16.33 lld-link: warning: ......\extensions\spellcheck\hunspell\glue\Unified_cpp_hunspell_glue0.obj: locally defined symbol imported: "public: bool __cdecl Hunspell::spell(class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>> const &, int *, class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>> *)" (?spell@Hunspell@@QEAA_NAEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@PEAHPEAV23@@Z) (defined in ......\extensions\spellcheck\hunspell\src\Unified_cpp_hunspell_src0.obj) [LNK4217]
0:16.33 lld-link: warning: ......\extensions\spellcheck\hunspell\glue\Unified_cpp_hunspell_glue0.obj: locally defined symbol imported: "public: class std::vector<class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>>, class std::allocator<class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>>>> __cdecl Hunspell::suggest(class std::basic_string<char, struct std::char_traits<char>, class std::allocator<char>> const &)" (?suggest@Hunspell@@QEAA?AV?$vector@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@V?$allocator@V?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@2@@std@@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@3@@Z) (defined in ......\extensions\spellcheck\hunspell\src\Unified_cpp_hunspell_src0.obj) [LNK4217]

Comment 1

[(Away)]

This happens a lot when we integrate external components.

lld-link: warning: ... locally defined symbol imported:

Almost always this means: the third-party library annotated its APIs with the expectation that it would be be built as its own DLL, but instead, we baked it directly into libxul, so the importation formalisms were unnecessary.

Usually this annotation is in a macro that we have to find and disable.

"public: __cdecl Hunspell::~Hunspell(void)"
"public: __cdecl Hunspell::Hunspell(char const *, char const *, char const *)"

When you see this happen to a ctor and dtor, it's a good sign that the annotation was placed on the whole class rather than individual functions. So let's find class Hunspell and aha, there's the annotation: https://searchfox.org/mozilla-central/rev/153feabebc2d13bb4c29ef8adf104ec1ebd246ae/extensions/spellcheck/hunspell/src/hunspell.hxx#98

Most well-engineered libraries offer an escape hatch for these annotations, so let's look near the definition of LIBHUNSPELL_DLL_EXPORTED to see if there are any clues: https://searchfox.org/mozilla-central/rev/153feabebc2d13bb4c29ef8adf104ec1ebd246ae/extensions/spellcheck/hunspell/src/hunvisapi.h#10

Line 4 looks promising: it seems like HUNSPELL_STATIC will make the problematic macro be empty. Can you try adding DEFINES['HUNSPELL_STATIC'] = True (or whatever incantation makes the build system happy) to hunspell's moz.build? I'm away from my regular machine this week so I can't experiment with it easily myself.

Comment 2

[Jorg K (CEST = GMT+2)]

Thanks, Dave, I'll try this tomorrow.

Comment 3

[Jorg K (CEST = GMT+2)]

I tried modifying extensions/spellcheck/hunspell/moz.build and extensions/spellcheck/hunspell/src/moz.build with no success.

Comment 4

[(Away)]

I can try to play with it next week.

Comment 5

[(Away)]

This patch seems to work on try, can you confirm it fixes things for you? https://hg.mozilla.org/try/rev/f6334c8e1893065291fb6d255aa8559c17ad1b89

You may need to touch all the hunspell sources or just do a clean build to be sure.

Comment 6

[Jorg K (CEST = GMT+2)]

No touching or clean build was required. Changing the makefiles triggered a make in those directories
0:35.58 extensions/spellcheck/hunspell/src
0:35.74 extensions/spellcheck/hunspell/glue
and the later the link error disappeared. I had only tried in "src" but not "glue" (comment #3).

Thanks. It would be great to get this landed soon.

Comment 7

[(Away)]

Attachment: Define HUNSPELL_STATIC to silence warnings on Windows about importing intra-DLL code

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f442d55e6351
Define HUNSPELL_STATIC to silence warnings on Windows about importing intra-DLL code r=nalexander

Comment 9

[Stefan Hindli [:stefan_hindli]]

https://hg.mozilla.org/mozilla-central/rev/f442d55e6351