753456 - Lightning not working, error loading calbasecomps.dll [Microsoft Visual C++ Runtime Error R6034]

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[Stefan Sitter [:ssitter]]

Lightning 1.7a1 (20120502041524) + Thunderbird 15.0a1 (20120508030200) works fine.

Lightning 1.7a1 (20120502041524) + Thunderbird 15.0a1 (20120509030200) fails to load calbasecomps.dll and therefore Lightning doesn't work.

Maybe we just need a fresh nightly Lightning build once Bug 752565 is fixed.

But maybe we need to adjust something because of the compiler switch to Visual Studio 2010 on Trunk (Thunderbird Bug 751592).

Comment 1

[Stefan Sitter [:ssitter]]

Starting Thunderbird will show a popup dialog:

    ---------------------------
    Microsoft Visual C++ Runtime Library
    Runtime Error!
    Program: ...\thunderbird.exe
    R6034
    An application has made an attempt to load the C runtime library incorrectly.
    Please contact the application's support team for more information.
    ---------------------------

Afterwards Thunderbird will start but report the following in error console:

Failed to load native module at path '...\components\calbasecomps.dll': (80004003) error 1114

Error: TypeError: Components.classes['@mozilla.org/calendar/datetime;1'] is undefined
Source File: chrome://calendar/content/calUtils.js Line: 78

Comment 3

[Alfred Kayser]

Still happening with the 10-5-2012 build.

Comment 4

[Stefan Sitter [:ssitter]]

Blocks testing work.

Comment 5

[Matthew Mecca [:mmecca]]

Mark, John, any idea where this might be going wrong?

Comment 7

[Mark Banner (:standard8)]

My bet is bug 751592 - we upgraded the Thunderbird builds to vs2010. So you'll need to get vs2010 installed on the windows VM and then we can update the mozconfigs.

Comment 8

[Stefan Sitter [:ssitter]]

My own Lightning package build with Visual Studio 2010 seems to work with the Thunderbird nightly build.

Who should we contact to get Visual Studio 2010 installed on the "cal-vm-win32-tbox" tinderbox?

Comment 9

[Philipp Kewisch [:Fallen][📱📆]]

I'm not sure if the circle of people that could do it has broadened now that Thunderbird is almost moved into mozilla.org release infra, but jhopkins or gozer would know who the best person to talk to is.

Comment 10

[Stefan Sitter [:ssitter]]

Filed Bug 757500 to get Visual C++ 2010 installed on the build slave and CCed jhopkins and gozer as suggested in previous comment.

Comment 11

[Ravi Abram]

Too long for this fix?  Not built since May 10th?

Comment 12

[Mark Banner (:standard8)]

(In reply to Ravi Krishnamurthy from comment #11)
> Too long for this fix?  Not built since May 10th?

Please be patient, as you know this is currently being worked on in other bugs. The main person co-ordinating this has also been doing so during his vacation. It'll get fixed soon.

Comment 13

[Ravi Abram]

I know that this is a build server issue.  We are close to approaching 1 month since the last lightning build for windows, as well as mac os.

Comment 14

[Stefan Sitter [:ssitter]]

Ravi, you can CC yourself on Bug 756116 to get information about the nightly build problems. You can get the hourly comm-aurora builds for testing here: https://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/tinderbox-builds/

Comment 15

[Kent James (:rkent)]

I'm not really sure what the master plan is here, and whether my observations are relevant to this bug or another, but I spent some time on this today and here's my $0.02

I use VS 2008, and Moz15 TB builds with --enable-calendar fail with unresolved external symbols. Investigating, I come across "Bug 732124 - Build errors with VC11 Beta - mixing MTd libs with MDd exes fail to link" because it modified some code that I believe is needed to get my VS 2008 builds working.

In summary, a new capability was added to the mozilla builds where two versions of xpcom_glue_s are now being built, one that uses the static CRT and the other the dynamic. Plain xpcom_glue_s uses the dynamic CRT, but when USE_STATIC_LIBS is enabled then the compile uses the static CRT. So current Lightning is mixing these two models, which is the source of my failed builds.

There are two solutions: either switch the glue library to xpcom_staticruntime_s.lib, or quit setting USE_STATIC_LIBS = 1. From my understanding of bug 732124, the best solution for Lightning would be to disable USE_STATIC_LIBS. The patch I give here allows my Lightning builds to succeed on Moz15 with VS 2008. Not sure what will happen with VS 2010.

Comment 16

[Kent James (:rkent)]

Attachment: remove USE_STATIC_LIBS to use dynamic CRT

Comment 17

[Stefan Sitter [:ssitter]]

Building Lightning with VS 2010 works fine for me.

Thunderbird switched its build tool chain to VS 2010 that is the official compiler as of Firefox 13 / Thunderbird 13. Lightning will switch its build tool chain to VS 2010 too once bug 757500 is fixed.

Comment 18

[Philipp Kewisch [:Fallen][📱📆]]

Could you check the annotations to see why we introduced USE_STATIC_LIBS? iirc there was some platform that required static libs to be built.

Also CC'ing Mark, he might know or remember why this is needed.

Comment 19

[Kent James (:rkent)]

If you believe that USE_STATIC_LIBS is the correct thing to do, then the other alternative is to switch to the new xpcom_staticruntime_s.lib introduced in Moz15 as I understand it. I would be happy to also show the patch with that alternative. Doing nothing and simply relying on "it seems to works in VS 2010" is, I believe, the wrong thing.

Personally I don't care which way you go. My personal interest in this is simply to allow me to build Lightning locally without custom patches using the VS 2008 that I currently have, as my standard ExQuilla unit tests use it. The public interest here is to maintain the compatibility of Lightning builds with the widest variety of VS versions possible.

Comment 20

[Matthew Mecca [:mmecca]]

My local builds on Win 7 using VS 2010 have been failing with:

xpcomglue_s.lib(nsCRTGlue.obj) : error LNK2019: unresolved external symbol __imp__rand referenced in function "void __cdecl NS_MakeRandomString(char *,int)" (?NS_MakeRandomString@@YAXPADH@Z)
xpcomglue_s.lib(nsCRTGlue.obj) : error LNK2019: unresolved external symbol __imp__srand referenced in function "void __cdecl NS_MakeRandomString(char *,int)" (?NS_MakeRandomString@@YAXPADH@Z)
xpcomglue_s.lib(nsCRTGlue.obj) : error LNK2019: unresolved external symbol __imp___fdopen referenced in function _printf_stderr
xpcomglue_s.lib(nsCRTGlue.obj) : error LNK2019: unresolved external symbol __imp___dup referenced in function _printf_stderr
calbasecomps.dll : fatal error LNK1120: 4 unresolved externals


Disabling USE_STATIC_LIBS with the proposed patch works for me.

Comment 21

[Stefan Sitter [:ssitter]]

I think the error above might happen if you do not specify ac_add_options --enable-jemalloc.

You could check if your mozconfig is similar to the official one, e.g. https://hg.mozilla.org/build/buildbot-configs/file/b442da7cef86/calendar/win32/comm-central/mozconfig-lightning

Comment 22

[Kent James (:rkent)]

--enable-jemalloc is not normally used on debug builds (at least by me) and that is where I have been having issues. Not sure of release builds (which use --enable-jemalloc) IIRC --enable-jemalloc is also what forced me to buy the pay version of VS instead of use the free one.

The missing symbols in Comment 20 are exactly the behaviour I fought against yesterday (with VS 2008) and solved with my patch. The discussion in Bug 732124 was really the key to me understanding all of this.

Comment 23

[Matthew Mecca [:mmecca]]

(In reply to Stefan Sitter from comment #21)
> I think the error above might happen if you do not specify ac_add_options
> --enable-jemalloc.

--enable-jemalloc works for me also.

Comment 24

[Stefan Sitter [:ssitter]]

The 2012-06-25 comm-aurora and comm-central nightly builds using Visual C++ 2010 are starting up fine for me. This was fixed by Bug 757500 and Bug 764939. 

Discussion regarding USE_STATIC_LIBS is continued in Bug 766685.