529169 - compile Fennec win32 desktop builds with VS8

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[darya.botova]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729)
Build Identifier: 20091116022232

There is an error when run Fennec because MSVCR80.dll was not found. But browser works.

Reproducible: Always

Steps to Reproduce:
1.Run Fennec
2.
3.
Actual Results:  
There is a message window "Unable To Locate Component"
-This application has failed to start because MSVCR80.dll was not found. Re-installing the application may fix this problem.-

Comment 1

[darya.botova]

Please, delete it...

Comment 2

[Aakash Desai [:aakashd]]

This happens on windows desktop builds and they are not supported by the development team. Unfortunately, this will not be fixed. Thank you for filing a bug on this. It was much appreciated.

Comment 3

[Stuart Parmenter]

no, we need to fix this.

Comment 4

[(not currently active) Ted Mielczarek]

You probably either need to:
a) --enable-jemalloc (which ships our own CRT)
b) set WIN32_REDIST_DIR=/path/to/redist/x86/Microsoft.VC80.CRT (usually something like C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT, but probably different on the slaves)

We might also need the same fix as bug 528903 for xulrunner/stub/Makefile.in.

Comment 5

[darya.botova]

no, it didn't help

Comment 6

[Ben Combee (:bcombee)]

Attachment: turn off static linking for xulrunner stub

Used the Prism patch as the base for this.  We're just turning off use of static libs for building the xulrunner stub, which allows proper dynamic linking to happen with recent MSVC libraries.

Comment 7

[Ben Combee (:bcombee)]

bug 528903 is the related issue with prism for future reference

Comment 8

[Benjamin Smedberg]

Comment on attachment 418417 [details] [diff] [review]
turn off static linking for xulrunner stub

USE_STATIC_LIBS is correct, at least in the jemalloc builds that we ship by default.

Comment 9

[Benjamin Smedberg]

That is, the stub will now search for the "special mozilla libc" which is likely not present in the search path.

Comment 10

[Ben Combee (:bcombee)]

Benjamin, jemalloc doesn't work for Win32 debug builds, so when building without it, you get the problem seen in this bug.

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

Ben Combee, maybe we should use some jemalloc makefile flags to set/not-set the USE_STATIC_LIBS

Comment 12

[Benjamin Smedberg]

Is this a local build where you get the error, or are you packaging up a debug build and running it on a different machine? If the former, the MSVC8 libraries should be installed in the system path. Perhaps some of the former weirdness we did looking for the CRT files in the local install directory should be un-done.

In either case this patch is incorrect in the release case (xulrunner+jemalloc), which is the most important one.

Comment 13

[Ben Combee (:bcombee)]

It is with a local build, but users have also complained on Fennec 1.9.2 nightlies for Win32.

Comment 14

[Ben Combee (:bcombee)]

Oh, and I've tried adding various libraries to system path on my own system without any success.

Comment 15

[Aki Sasaki (not active)]

Attachment: enable jemalloc on win32 fennec desktop

Stuart says enabling jemalloc (along with https://bugzilla.mozilla.org/show_bug.cgi?id=518910#c4 ) will fix this.

Comment 16

[Ben Combee (:bcombee)]

This may fix it for our nightly releases, but jemalloc + Win debug build is broken IIRC.

Comment 17

[Stuart Parmenter]

I verified that --enable-jemalloc fixes the problem, but jemalloc requires a SP1 of VS2008 which isn't on the build machines...

Comment 18

[Nick Thomas [:nthomas] (UTC+12)]

AIUI --enable-jemalloc requires VS2005 SP1, rather than VS2008. Did that change ?

Comment 19

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

This continues to block desktop win32 fennec builds, but there is a manual
workaround for now (Stuart doing on his machines).

Unknown how easy/hard to roll out using OPSI. Moving to Future until after we
spin up the new hardware and can revisit.

Comment 20

[(not currently active) Ted Mielczarek]

nthomas: bug 416117 fixed --enable-jemalloc to work with VS2008 SP1.

Comment 21

[Stuart Parmenter]

any ETA on this?

Comment 22

[Aki Sasaki (not active)]

The fastest way to having win32 desktop Fennec builds would probably be to back out the --enable-jemalloc.

Otherwise [I think] it's a matter of

a) download correct sp1
b) generate opsi package that will install vs9 sp1 automatically
c) test on staging; if paranoid test winmo builds on said box
d) enable on production opsi server
e) roll out to 60?+ win32 slaves while they're not building/running tests

which, even if we assign someone to work on this immediately, probably won't happen by the end of the week.  However, once this is done, new win32 slaves will have vs9 sp1 installed by default.

Comment 23

[Chris Cooper [:coop] (he/him)]

Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

Comment 24

[Aki Sasaki (not active)]

jemalloc should build with either vs9sp1 or our current vs8 setup.

Since there is a greater lead time to create an sp1 opsi package, and there isn't a specific reason we're using vs9 instead of vs8 to build win32 fennec desktop builds, downgrading seems like an expedient solution.

Comment 25

[Aki Sasaki (not active)]

The compile worked once I renamed mozilla-build/vim/vim72/install.exe to viminstall.exe.  However, make package then failed with:

xulrunner/xulrunner.exe
Linking XPT files...
Stripping package directory...
signing nss libraries
/bin/sh: ../../dist/bin/shlibsign: No such file or directory
/bin/sh: ../../dist/bin/shlibsign: No such file or directory
Rebasing  ../../dist/fennec
/bin/find  ../../dist/fennec -name "*.dll" -a -not -name "MSVC*" | sort | xargs rebase -b 60000000

REBASE: Total Size of mapping 0x0000000001490000
REBASE: Range 0x0000000060000000 -0x0000000061490000
make[2]: Leaving directory `/e/builds/moz2_slave/w32mob-trunk-nightly/mozilla-central/objdir/mobile/mobile/installer'
make[1]: Leaving directory `/e/builds/moz2_slave/w32mob-trunk-nightly/mozilla-central/objdir/mobile/mobile/installer'
make[2]: *** [stage-package] Error 123
make[1]: *** [all] Error 2
make: *** [package] Error 2

Comment 26

[Aki Sasaki (not active)]

Attachment: fennec win32 -> vs8 configs

Ok, the above is an m-c bug. This worked on m-1.9.2.

Comment 27

[Aki Sasaki (not active)]

Attachment: fennec win32 -> vs8 custom

yay removing code

Comment 28

[Aki Sasaki (not active)]

Comment on attachment 427481 [details] [diff] [review]
fennec win32 -> vs8 configs

http://hg.mozilla.org/build/buildbot-configs/rev/7bc94c58b0f5

Comment 29

[Aki Sasaki (not active)]

Comment on attachment 427482 [details] [diff] [review]
fennec win32 -> vs8 custom

http://hg.mozilla.org/build/buildbotcustom/rev/dafa2b05c50f

Comment 30

[Aki Sasaki (not active)]

Hitting the same vim/install.exe issue, since I only renamed it on staging slaves.  Looks like we need to choose a solution out of

- rename the mozilla-build\vim72\vim\install.exe on all production slaves + opsi
- use nsinstall instead of install ? (possible?)
- change the path
- something else

Comment 31

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #30)
> Hitting the same vim/install.exe issue, since I only renamed it on staging
> slaves.  Looks like we need to choose a solution out of
> 
> - rename the mozilla-build\vim72\vim\install.exe on all production slaves +
> opsi

There's already a package to do this on bug 541953.

Comment 32

[Aki Sasaki (not active)]

win32 fennec 1.9.2 nightly just went green.