794238 - Problems with getting clean VS C++ debug build with Gecko SDK

Status: RESOLVED INCOMPLETE

(Firefox Build System :: General, defect)

Description

[Yuriy Look]

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; GTB7.4; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.3; .NET4.0C; .NET4.0E)

Steps to reproduce:

This is probably related to a presumable move of bulds of Windows Gecko SDK to Visual Studio 2010 between versions 10 and 17.

If I produce a debug build against Windows Gecko sdk with VS 2008, warnings similar to the come out:

xpcomglue_s.lib(nsTArray.obj) : warning LNK4229: invalid directive '/FAILIFMISMATCH:_MSC_VER=1600' encountered; ignored
xpcomglue_s.lib(nsTArray.obj) : warning LNK4229: invalid directive '/FAILIFMISMATCH:_ITERATOR_DEBUG_LEVEL=0' encountered; ignored

According to http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/76af63c9-dba7-4323-9fd2-87f5a33e75e7 Microsoft publication, the level of risk of having problems because of using VS 2008 with the library built with VS 2010 is very low, and is only related to the usage of C++ standard library.  

Nevertheless, there is some risk, and I'd guess there was a reason behind introducing this feature by Microsoft.

If I build the same code with VS 2010, I get errors similar to the following:

 xpcomglue_s.lib(nsTArray.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in MozillaBasicNodeHelper.obj

Release build in VS 2010 does not have such problems.



Actual results:

I tried other incarnations of xpcomglue, like xpcomglue.lib with the same result.


Expected results:

Looks like at least some .lib files that come with Gecko SDK shoud come in two versions -- Relase and Debug, like many other libraries, both from Microsoft and other sources, so that developers can build debug versions of their C++ applications .

Comment 1

[Alex Keybl [:akeybl]]

Glandium - shot in the dark that you may be able to help Yury out.

Comment 2

[Mike Hommey [:glandium]]

I'm not too versed on these kind of msvc details.

Comment 3

[Benjamin Smedberg]

It is unlikely that we can fix this easily. You can build your own gecko SDK to work around this issue if necessary (although VC2008 is no longer supported).

Comment 4

[Yuriy Look]

@Benjamin Smedberg [:bsmedberg] 
I did not mean to have a debug build in VS 2008.  Like with "notmal" enterprize product, it's customary that debug build with the *same* compiler that is used to make a release build is also made available.  MS CRT and MFC would be the most obvious examples.  It's quit opposite, I have to do debug build in VS 2008, where this mentioned match is not required.  I am pretty sure Mozilla developers do make a debug build.  If as you say, it cannot be done easily by Mozilla, what would you expect from outside developers, some of whom, like myself, work on Mozilla stuff only parttime and making a proprietary Gecko SDK build, which cannot be anything other than a heavy burden.

Comment 5

[Benjamin Smedberg]

The recommended solution is to stop using binary XPCOM and stop using the SDK. But absent that, compiling XULRunner yourself is not a big deal and produces an SDK you can use.

Comment 6

[Yuriy Look]

@Benjamin Smedberg [:bsmedberg] 
Maybe you can elaborate more on "stop using binary XPCOM and stop using the SDK".  How whould you recommend building binaries that use the interfaces from xpcom.lib?  Is there anything posted on Mozilla websites?