windows bustage: calbasecomps.dll : fatal error LNK1120: 13 unresolved externals

RESOLVED FIXED in Thunderbird 35.0

Status

Thunderbird
Build Config
--
blocker
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: Magnus Melin, Assigned: Ian Neal)

Tracking

({regression})

35 Branch
Thunderbird 35.0
x86_64
Windows 7
regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

4 years ago
Windows builds have been busted for some time now. Couldn't find a bug so here it is.

https://tbpl.mozilla.org/php/getParsedLog.php?id=47410288&tree=Thunderbird-Trunk&full=1

calbasecomps.dll : fatal error LNK1120: 13 unresolved externals

mozmake.exe[5]: *** [calbasecomps.dll] Error 1120
mozmake.exe[4]: *** [calendar/base/backend/libical/build/target] Error 2
mozmake.exe[4]: *** Waiting for unfinished jobs....
mozmake.exe[3]: *** [compile] Error 2
mozmake.exe[2]: *** [default] Error 2
mozmake.exe[1]: *** [build] Error 2
mozmake.exe: *** [build] Error 2
I'm not sure why this is happening in windows and not on other platforms. I had hoped that bug 1063085 would fix it but I've read reports that it only cuts down 3 unresolved symbols. Could you paste the missing symbols here again? I could imagine that some recent build system change did something with library include paths. Maybe the new XpcomBinaryComponent() thing isn't working as expected?
(Reporter)

Comment 2

4 years ago
Do you mean (see the link)

xpcomglue_s.lib(Unified_cpp_xpcom_glue1.obj) : error LNK2019: unresolved external symbol __imp__wcspbrk referenced in function "wchar_t * __cdecl wcspbrk(wchar_t *,wchar_t const *)" (?wcspbrk@@YAPA_WPA_WPB_W@Z)

xpcomglue_s.lib(Unified_cpp_xpcom_glue1.obj) : error LNK2019: unresolved external symbol __imp___wfopen referenced in function "struct _iobuf * __cdecl TS_tfopen(char const *,wchar_t const *)" (?TS_tfopen@@YAPAU_iobuf@@PBDPB_W@Z)

xpcomglue_s.lib(Unified_cpp_xpcom_glue1.obj) : error LNK2019: unresolved external symbol __imp__wcstol referenced in function "wchar_t * __cdecl ParseVP(wchar_t *,struct VersionPartW &)" (?ParseVP@@YAPA_WPA_WAAUVersionPartW@@@Z)

xpcomglue_s.lib(Unified_cpp_xpcom_glue1.obj) : error LNK2019: unresolved external symbol __imp__rand referenced in function "public: static unsigned int __cdecl mozilla::ChaosMode::randomUint32LessThan(unsigned int)" (?randomUint32LessThan@ChaosMode@mozilla@@SAII@Z)

xpcomglue_s.lib(Unified_cpp_xpcom_glue0.obj) : error LNK2001: unresolved external symbol __imp__rand

xpcomglue_s.lib(Unified_cpp_xpcom_glue1.obj) : error LNK2019: unresolved external symbol __imp__wcsncmp referenced in function "int __cdecl CompareVP(struct VersionPartW &,struct VersionPartW &)" (?CompareVP@@YAHAAUVersionPartW@@0@Z)

xpcomglue_s.lib(Unified_cpp_xpcom_glue1.obj) : error LNK2019: unresolved external symbol __imp__wcsdup referenced in function "int __cdecl mozilla::CompareVersions(wchar_t const *,wchar_t const *)" (?CompareVersions@mozilla@@YAHPB_W0@Z)

OLDNAMES.lib(wcsdup.obi) : error LNK2001: unresolved external symbol __imp__wcsdup

xpcomglue_s.lib(Unified_cpp_xpcom_glue1.obj) : error LNK2019: unresolved external symbol __imp__fread referenced in function "private: enum tag_nsresult __thiscall nsINIParser::InitFromFILE(struct _iobuf *)" (?InitFromFILE@nsINIParser@@AAE?AW4tag_nsresult@@PAU_iobuf@@@Z)

xpcomglue_s.lib(Unified_cpp_xpcom_glue1.obj) : error LNK2019: unresolved external symbol __imp__ftell referenced in function "private: enum tag_nsresult __thiscall nsINIParser::InitFromFILE(struct _iobuf *)" (?InitFromFILE@nsINIParser@@AAE?AW4tag_nsresult@@PAU_iobuf@@@Z)

xpcomglue_s.lib(Unified_cpp_xpcom_glue1.obj) : error LNK2019: unresolved external symbol __imp__fseek referenced in function "private: enum tag_nsresult __thiscall nsINIParser::InitFromFILE(struct _iobuf *)" (?InitFromFILE@nsINIParser@@AAE?AW4tag_nsresult@@PAU_iobuf@@@Z)

xpcomglue_s.lib(Unified_cpp_xpcom_glue0.obj) : error LNK2019: unresolved external symbol __imp__srand referenced in function "void __cdecl NS_MakeRandomString(char *,int)" (?NS_MakeRandomString@@YAXPADH@Z)

xpcomglue_s.lib(Unified_cpp_xpcom_glue0.obj) : error LNK2019: unresolved external symbol __imp___fdopen referenced in function _vprintf_stderr

xpcomglue_s.lib(Unified_cpp_xpcom_glue0.obj) : error LNK2019: unresolved external symbol __imp___dup referenced in function _vprintf_stderr

xpcomglue_s.lib(Unified_cpp_xpcom_glue0.obj) : error LNK2019: unresolved external symbol __imp__vsnprintf referenced in function _vprintf_stderr
Similar errors in the past were related to static linking. I see that in the recent past e.g. Bug 1052943, Bug 1049247 and Bug 1060890 changed the usage of static link on comm-central (USE_STATIC_LIBS). 
Maybe the calendar code needs an update too?
http://mxr.mozilla.org/comm-central/search?string=USE_STATIC_LIBS&find=/calendar/
Created attachment 8485489 [details] [diff] [review]
Fix - v1

Great hint! It seems USE_STATIC_LIBS was moved to moz.build, this patch fixes. Note though I haven't actually tested the patch since I don't have my windows machine set up for the build currently.

Here is a try run, I hope there are no other issues that might cause failures:
https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=ea54f0f8ed65
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #8485489 - Flags: review?(ssitter)
(Assignee)

Comment 5

4 years ago
I think I know why this is only happening on the Windows platform and it is related to the XpcomBinaryComponent() change.
If you look at http://hg.mozilla.org/mozilla-central/diff/62b9f6d4328b/build/templates.mozbuild
You can see it only allows for xpcomglue_s and not for xpcomglue_staticruntime_s
Comment on attachment 8485489 [details] [diff] [review]
Fix - v1

Ok, that didn't seem to do it. Instead, there are a few new warnings about locally defined symbols being imported.
Attachment #8485489 - Flags: review?(ssitter)
(In reply to Ian Neal from comment #5)
> I think I know why this is only happening on the Windows platform and it is
> related to the XpcomBinaryComponent() change.
> If you look at
> http://hg.mozilla.org/mozilla-central/diff/62b9f6d4328b/build/templates.
> mozbuild
> You can see it only allows for xpcomglue_s and not for
> xpcomglue_staticruntime_s

That would explain why its just failing on windows. This is probably a bug worth fixing in the build system, but I've started another try run that doesn't use the template but instead the variables it defines on its own.

https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=bb1f047f2c52
(Assignee)

Comment 8

4 years ago
To quote from bug 937900 comment 0:
>From bug 937359 comment 6:
>
>> browser/components is probably safe to remove: we linked it statically
>> against the CRT back when the CRT was a Windows assembly and it was causing
>> problems that components/browsercomps.dll was in a subdirectory and couldn't
>> find the assembly.
>
> Digging in the history of the corresponding Makefiles, I found bug 713167 in which it is claimed
> that the problem may have gone with msvc 2010, which we now require. I'll try this in a separate 
> bug, as it can have implications that the other parts don't.
(Assignee)

Comment 9

4 years ago
And by that quote, I meant to say do we actually still need to statically link against the CRT?
(Assignee)

Comment 10

4 years ago
Try attempt with no static linking:
https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=6fac494969be
Ian, thanks for digging this up. It looks like it works! I've taken a look at the patch from your try build and if you want to push it, r=philipp.
Assignee: philipp → iann_bugzilla
I've also tested the builds on a windows 7 machine and they works as expected.
(Assignee)

Comment 13

4 years ago
Created attachment 8485536 [details] [diff] [review]
Do not statically link anymore [Checked in: Comment 14]
Attachment #8485489 - Attachment is obsolete: true
Attachment #8485536 - Flags: review+
(Assignee)

Comment 14

4 years ago
Comment on attachment 8485536 [details] [diff] [review]
Do not statically link anymore [Checked in: Comment 14]

http://hg.mozilla.org/comm-central/rev/4ec1bfcdda82
Attachment #8485536 - Attachment description: Do not statically link anymore → Do not statically link anymore [Checked in: Comment 14]
(Assignee)

Updated

4 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 35.0
You need to log in before you can comment on or make changes to this bug.