Install Visual C++ 2010 on build slaves

RESOLVED FIXED

Status

Release Engineering
Other
P3
normal
RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: ted, Assigned: rail)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [opsi][buildslaves])

Attachments

(3 attachments, 2 obsolete attachments)

(Reporter)

Description

7 years ago
I'd like to switch trunk builds to use Visual C++ 2010 now that it's been officially released. This should fix some bugs we have with Breakpad symbol dumping, and it's also likely to give us a small performance increase.

First, we need to get it installed on the build slaves. I'll file a separate bug for actually making it the compiler used for trunk builds.
(Reporter)

Updated

7 years ago
Blocks: 563318
Ideally this is wanted for the alpha cycle for 3.7.
Priority: -- → P5
Whiteboard: [3.7alpha][opsi][buildslaves]
(Assignee)

Updated

7 years ago
Assignee: nobody → rail
Status: NEW → ASSIGNED
Priority: P5 → P4
(Assignee)

Updated

7 years ago
Depends on: 563666

Updated

7 years ago
Whiteboard: [3.7alpha][opsi][buildslaves] → [opsi][buildslaves]
(Assignee)

Updated

7 years ago
Depends on: 604593
(Assignee)

Comment 2

7 years ago
Created attachment 483418 [details] [diff] [review]
Visual Studio 2010 OPSI packages

Attached OPSI packages worked well on an ix slave, but not on VM (see bug 604593, not enough disk space on C:).

Unattend ini file was created by running
setup\setup.exe /createunattend d:\vs2010.ini
I went through all steps and selected C/C++ component only.

To make OPSI happy I removed the directory with product docs (1.2G), otherwise OPSI was complaining about "unexpected EOF of cpio file" which usually happens for files >2G.
(Assignee)

Comment 3

7 years ago
Back to the pool, until the blocker is resolved.
Assignee: rail → nobody
Status: ASSIGNED → NEW
Priority: P4 → --

Comment 4

7 years ago
Are we going to have to be careful to reserve some build slaves with the older version of Visual C++ ?  Do they co-exist in a way that won't break one or the other?
(Reporter)

Comment 5

7 years ago
They can coexist just fine, and I believe our existing setup to select the SDK per-branch should let us select a compiler per-branch without much trouble.
(In reply to comment #3)
> Back to the pool, until the blocker is resolved.

Rail, blocker is now resolved.  Please throw back in the pool if you don't have time to look into this.
Assignee: nobody → rail
(Assignee)

Updated

6 years ago
Priority: -- → P3
(Reporter)

Comment 7

6 years ago
khuey is actively working on bug 515492, which is the code blocker for switching our builds to VC 2010. Can we get this back on the radar so we can test with it and hopefully switch our builds to use it in the near future?
Priority: P3 → --

Updated

6 years ago
Whiteboard: [opsi][buildslaves] → [opsi][buildslaves][triagefollowup]
(Assignee)

Comment 8

6 years ago
I'm not sure if I can work on this bug this and next month. Back to the pool.
Assignee: rail → nobody
Can we install this to all the ix machines at least, and then do our windows builds on just the ix slaves?
(In reply to comment #9)
> Can we install this to all the ix machines at least, and then do our windows
> builds on just the ix slaves?

Yes, I think this is the correct path forward here. We already do everything we can to make sure our builds don't end up running on VMs. Maybe we can just make that a hard rule for branches that need VC 2010.

Rail: does that improve your outlook for this bug if you only have to worry about ix machines?
Whiteboard: [opsi][buildslaves][triagefollowup] → [opsi][buildslaves]
(In reply to comment #10)
> (In reply to comment #9)
> > Can we install this to all the ix machines at least, and then do our windows
> > builds on just the ix slaves?
> 
> Yes, I think this is the correct path forward here. We already do everything
> we can to make sure our builds don't end up running on VMs. Maybe we can
> just make that a hard rule for branches that need VC 2010.
> 
> Rail: does that improve your outlook for this bug if you only have to worry
> about ix machines?

With the large majority of our branches being M-C (and thus, i assume vc 2010 once installed), should we consider retiring the windows vms full stop?  They have horrid performance (pgo builds take 8+ hours vs 3.5 hours on hardware) and as mentioned, we do everything to avoid them.  As an anecdote, the build times also suggest that its better for us to wait for an entire pgo build to finish than it is to start a build on a vm.
We're working on the build times on VMs, by the way - bug 659436.  But I'm not opposed to getting rid of them.
Do we have stats on how busy each slave is?
Other than what you can dig up in buildapi, no -- but that's probably a good source to use.

Updated

6 years ago
Priority: -- → P3
Actually, the typical VM build time isn't 8 hours, it's more like 7.5: 4 hours including the "10800 seconds without output" to burn, then 3.5 for the retriggered build to run on hardware. (Wallclock is a little worse, since most people don't know what happened to their build, so there's a lag while they fret about it before asking someone who does know.)
(In reply to comment #15)
> Actually, the typical VM build time isn't 8 hours, it's more like 7.5: 4
> hours including the "10800 seconds without output" to burn, then 3.5 for the
> retriggered build to run on hardware. (Wallclock is a little worse, since
> most people don't know what happened to their build, so there's a lag while
> they fret about it before asking someone who does know.)

Sometimes they complete, and when they do they are >8 hours.
Can we seclude the Win32 VMs to only take debug builds and stop taking optimized builds? win-win?
11 hours and 27 minutes for this morning's merge from mozilla-inbound to build on Windows.
Created attachment 543118 [details] [diff] [review]
Restrict windows dep builds to use only 'fast' slaves
Attachment #543118 - Flags: review?(bhearsum)
Attachment #543118 - Flags: review?(bhearsum) → review+
So, what's blocking this now?

Updated

6 years ago
Attachment #483418 - Flags: review+
(Assignee)

Updated

6 years ago
Assignee: nobody → rail
Priority: P3 → P2
(Assignee)

Comment 21

6 years ago
Created attachment 558256 [details] [diff] [review]
VS2010 OPSI package

Turned out that uninstall program doesn't unistall pre requirements which were installed by it. To test the OPSI package I used the same slave which was ready for rebootless setup. That time we had only one staging slave with enough disk space.

When I tried to test the package on a fresh slave I figured out that the installer needs at least 2 reboots.

Updated patch is attached. Testing it in staging.
Attachment #483418 - Attachment is obsolete: true
(Assignee)

Comment 22

6 years ago
I tried to install the adapted opsi package on the following staging slaves:

mw32-ix-slave01
mw32-ix-slave19
mw32-ix-slave21
w32-ix-slave01

w32-ix-slave01 was unable to install anything in foreground. After short investigation I found that this slave had incomplete opsi installation (or incorrect?). pgina/pgina.dll file was missing and there was no registry entry to enforce pgina.dll as a login dll. I reinstalled opsi on w32-ix-slave01 per https://wiki.mozilla.org/ReleaseEngineering:OPSI#Re-installing_OPSI and it seems that installation works properly now.

However, to make sure that everything works as expected before we deploy the package to production slaves, I would like to suggest the following scenario:

1) reimage 2 staging slaves
2) install VS2010 on these slaves using OPSI (the patch for review incoming)
3) Validate VS2010 installation by giving the slave(s) to a dev
4) ???
5) Profit: Go production :D
(Assignee)

Comment 23

6 years ago
Created attachment 558413 [details] [diff] [review]
VS2010 OPSI package
Attachment #558413 - Flags: review?(catlee)
(Assignee)

Updated

6 years ago
Depends on: 684816

Updated

6 years ago
Attachment #558413 - Flags: review?(catlee) → review+
(Assignee)

Updated

6 years ago
Depends on: 685109
I tested the install on the slave provided to me by Rail by doing a debug build and an opt PGO build of Firefox.  I had to make the following changes to build successfully:

- Install a newer version of MozillaBuild (one with start-msvc10.bat files).
- Change WIN32_REDIST_DIR to point to the redist directory for MSVC 2010.

After those two changes I was able to build and run both debug and opt PGO builds.
(Assignee)

Comment 25

6 years ago
Comment on attachment 558413 [details] [diff] [review]
VS2010 OPSI package

http://hg.mozilla.org/build/opsi-package-sources/rev/816402adc761
Attachment #558413 - Flags: checked-in+
(Assignee)

Updated

6 years ago
Attachment #558256 - Attachment is obsolete: true
(Assignee)

Comment 26

6 years ago
All try IX slaves have Visual Studio 2010 installed. Before we deploy it to production it would be great to test it try. We don't have any good solution for switching compilers right now. Ideas are welcome.

I ran "set" using plain cmd and after setting env variables by vs2010 shell and below are the differences:

DevEnvDir=D:\msvs10\Common7\IDE\
Framework35Version=v3.5
FrameworkDIR32=c:\WINDOWS\Microsoft.NET\Framework\
FrameworkDir=c:\WINDOWS\Microsoft.NET\Framework\
FrameworkVersion32=v4.0.30319
FrameworkVersion=v4.0.30319
INCLUDE=D:\msvs10\VC\INCLUDE;D:\msvs10\VC\ATLMFC\INCLUDE;c:\Program Files\Microsoft SDKs\Windows\v7.0A\include;
LIB=D:\msvs10\VC\LIB;D:\msvs10\VC\ATLMFC\LIB;c:\Program Files\Microsoft SDKs\Windows\v7.0A\lib;
LIBPATH=c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;c:\WINDOWS\Microsoft.NET\Framework\v3.5;D:\msvs10\VC\LIB;D:\msvs10\VC\ATLMFC\LIB;
Path=D:\msvs10\VSTSDB\Deploy;D:\msvs10\Common7\IDE\;D:\msvs10\VC\BIN;D:\msvs10\Common7\Tools;c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319;c:\WINDOWS\Microsoft.NET\Framework\v3.5;D:\msvs10\VC\VCPackages;C:\Program Files\HTML Help Workshop;c:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools;c:\Program Files\Microsoft SDKs\Windows\v7.0A\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Intel\DMIX;d:\mozilla-build\python25;C:\Program Files\Microsoft SQL Server\90\Tools\binn\;D:\sdks\tegra042\\tools;D:\sdks\tegra042\\platformlibs\bin\winxp\x86\release;D:\sdks\tegra042\\3rdparty\bin\winxp\x86\release;d:\mozilla-build\python25\scripts;D:\mozilla-build\hg\bin
VCINSTALLDIR=D:\msvs10\VC\
VSINSTALLDIR=D:\msvs10\
WindowsSdkDir=c:\Program Files\Microsoft SDKs\Windows\v7.0A\
Thanks.  I'll try to hack up some stuff to use the new compiler on try.  Unfortunately, that's not likely to happen this week.
(Assignee)

Comment 28

6 years ago
What do you think about the following idea.

ATM, we set up VS related environment variables globally for buildslave process and they are available in every step, what kind of prevents or complicates setting environment variables for multiple compilers.

VS sets VSxxxCOMNTOOLS env variable globally (http://people.mozilla.org/~raliiev/sattap/f2d1e3bc.png), which can be used to detect the directory where vcvarsall.bat lives so it can be used to set up vars for Makefiles. So if you put "ac_add_options --with-vc10|--with-vc8" to mozconfig make would use it, find vcvarsall.bat, eval variables and set env for Makefiles.
(Reporter)

Comment 29

6 years ago
That's pretty far away from how things work on any other platform, I don't know that I'd like to go that route.
I pushed a patch to try that appended the following to browser/config/mozconfigs/win32/nightly:
export INCLUDE="D:/msvs10/VC/INCLUDE;D:/msvs10/VC/ATLMFC/INCLUDE;c:/Program Files/Microsoft SDKs/Windows/v7.0A/include;"
export LIB="D:/msvs10/VC/LIB;D:/msvs10/VC/ATLMFC/LIB;c:/Program Files/Microsoft SDKs/Windows/v7.0A/lib;"
export LIBPATH="c:/WINDOWS/Microsoft.NET/Framework/v4.0.30319;c:/WINDOWS/Microsoft.NET/Framework/v3.5;D:/msvs10/VC/LIB;D:/msvs10/VC/ATLMFC/LIB;"
export PATH="/D/msvs10\VSTSDB\Deploy:/D/msvs10\Common7\IDE\:/D/msvs10\VC\BIN:/D/msvs10\Common7\Tools:/c/WINDOWS\Microsoft.NET\Framework\v4.0.30319:/c/WINDOWS\Microsoft.NET\Framework\v3.5:/D/msvs10\VC\VCPackages:/C/Program Files\HTML Help Workshop:/c/Program Files\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools:/c/Program Files\Microsoft SDKs\Windows\v7.0A\bin:/C/WINDOWS\system32:/C/WINDOWS:/C/WINDOWS\System32\Wbem:/C/Program Files\Intel\DMIX:/d/mozilla-build\python25:/C/Program Files\Microsoft SQL Server\90\Tools\binn\:/D/sdks\tegra042\\tools:/D/sdks\tegra042\\platformlibs\bin\winxp\x86\release:/D/sdks\tegra042\\3rdparty\bin\winxp\x86\release:/d/mozilla-build\python25\scripts:/D/mozilla-build\hg\bin:$PATH"
export WIN32_REDIST_DIR="/d/msvs10/VC/redist/x86/Microsoft.VC100.CRT"


Seems to be compiling. Results will be here: https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=7153087f36d4

Builds will be here if they succeed: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bhearsum@mozilla.com-7153087f36d4
It ended up failing with:
sqlite3.c
d:/mozilla-build/python25/python2.5.exe -O e:/builds/moz2_slave/try-w32/build/build/cl.py cl -Fosqlite3.obj -c  -DSQLITE_SECURE_DELETE=1 -DSQLITE_THREADSAFE=1 -DSQLITE_CORE=1 -DSQLITE_ENABLE_FTS3=1 -DSQLITE_ENABLE_UNLOCK_NOTIFY=1 -DSQLITE_DEFAULT_PAGE_SIZE=32768 -DSQLITE_MAX_DEFAULT_PAGE_SIZE=32768 -DSQLITE_MAX_SCHEMA_RETRY=25  -DOSTYPE=\"WINNT5.2\" -DOSARCH=WINNT -I/e/builds/moz2_slave/try-w32/build/db/sqlite3/src -I/e/builds/moz2_slave/try-w32/build/db/sqlite3/src -I. -I../../../dist/include -I../../../dist/include/nsprpub  -Ie:/builds/moz2_slave/try-w32/build/obj-firefox/dist/include/nspr -Ie:/builds/moz2_slave/try-w32/build/obj-firefox/dist/include/nss        -TC -nologo -W3 -Gy -Fdgenerated.pdb -we4553  -DNDEBUG -DTRIMMED -Zi -Zi -UDEBUG -DNDEBUG -O1 -Oy -MD            -FI ../../../dist/include/mozilla-config.h -DMOZILLA_CLIENT /e/builds/moz2_slave/try-w32/build/db/sqlite3/src/sqlite3.c
sqlite3.c

e:/builds/moz2_slave/try-w32/build/db/sqlite3/src/sqlite3.c(313) : fatal error C1083: Cannot open include file: 'stdint.h': No such file or directory


Seems like I may have buggered up INCLUDE.
(Assignee)

Comment 32

6 years ago
I'll try to play with env today/tomorrow.
(Assignee)

Comment 33

6 years ago
I got the same failures for https://hg.mozilla.org/try/rev/6cc08ec68833 with the following additions to the mozconfig:

=================================
export LIB="D:\msvs10\VC\LIB;D:\msvs10\VC\ATLMFC\LIB;${LIB}"
export LIBPATH="D:\msvs10\VC\LIB;D:\msvs10\VC\ATLMFC\LIB;${LIBPATH}"
export PATH="/d/msvs10/VSTSDB/Deploy:/d/msvs10/Common7/IDE/:/d/msvs10/VC/BIN:/d/msvs10/Common7/Tools:/d/msvs10/VC/VCPackages:${PATH}"
export INCLUDE="D:\msvs10\VC\INCLUDE;D:\msvs10\VC\ATLMFC\INCLUDE;${INCLUDE}"
export WIN32_REDIST_DIR="/d/msvs10/VC/redist/x86/Microsoft.VC100.CRT"
=================================

Any idea why it may fail?

stdint.h is in D:\msvs10\VC\INCLUDE which is in $INCLUDE
(In reply to Rail Aliiev [:rail] from comment #33)
> I got the same failures for https://hg.mozilla.org/try/rev/6cc08ec68833 with
> the following additions to the mozconfig:
> 
> =================================
> export LIB="D:\msvs10\VC\LIB;D:\msvs10\VC\ATLMFC\LIB;${LIB}"
> export LIBPATH="D:\msvs10\VC\LIB;D:\msvs10\VC\ATLMFC\LIB;${LIBPATH}"
> export
> PATH="/d/msvs10/VSTSDB/Deploy:/d/msvs10/Common7/IDE/:/d/msvs10/VC/BIN:/d/
> msvs10/Common7/Tools:/d/msvs10/VC/VCPackages:${PATH}"
> export INCLUDE="D:\msvs10\VC\INCLUDE;D:\msvs10\VC\ATLMFC\INCLUDE;${INCLUDE}"
> export WIN32_REDIST_DIR="/d/msvs10/VC/redist/x86/Microsoft.VC100.CRT"
> =================================
> 
> Any idea why it may fail?

are those being passed verbatim to the shell, or are those the actual values, could you be hitting an issue where you need to escape or even double-escape the path chars for win style paths?
(Assignee)

Comment 35

6 years ago
mozconfigs are being sourced by shell (bash?). Backslashes should be passed as is, there is no need to escape them when you *source* from a file, afaik. So backslashes should be an issue here.
(Assignee)

Comment 36

6 years ago
Any other thoughts?
(Reporter)

Comment 37

6 years ago
bhearsum's comment 30 is using all forward-slashes and it seems to be hitting the same problem, so that's unlikely to be the issue.
(Assignee)

Comment 38

6 years ago
I changed cl.py to dump env vars in case of failure and it printed the following:

LIB=D:\sdks\v7.0\\lib;D:\msvs8\VC\ATLMFC\LIB;D:\msvs8\VC\LIB;D:\msvs8\VC\PlatformSDK\lib;D:\msvs8\SDK\v2.0\lib;;D:\mozilla-build\\atlthunk_compat;d:\sdks\dx10\lib\x86

INCLUDE=D:\sdks\v7.0\\include;D:\sdks\v7.0\\include\atl;D:\msvs8\VC\ATLMFC\INCLUDE;D:\msvs8\VC\INCLUDE;D:\msvs8\VC\PlatformSDK\include;;d:\sdks\dx10\include

PATH=D:\mozilla-build\msys\local\bin;d:\mozilla-build\wget;d:\mozilla-build\7zip;d:\mozilla-build\blat261\full;d:\mozilla-build\python25;d:\mozilla-build\svn-win32-1.6.3\bin;d:\mozilla-build\upx203w;d:\mozilla-build\emacs-22.3\bin;d:\mozilla-build\info-zip;d:\mozilla-build\nsis-2.22;d:\mozilla-build\nsis-2.33u;d:\mozilla-build\hg;d:\mozilla-build\python25\Scripts;d:\mozilla-build\kdiff3;d:\mozilla-build\vim\vim72;d:\mozilla-build\yasm;.;D:\mozilla-build\msys\local\bin;D:\mozilla-build\msys\mingw\bin;D:\mozilla-build\msys\bin;d:\sdks\v7.0\bin;d:\msvs8\Common7\IDE;d:\msvs8\VC\BIN;d:\msvs8\Common7\Tools;d:\msvs8\Common7\Tools\bin;d:\msvs8\VC\PlatformSDK\bin;d:\msvs8\SDK\v2.0\bin;c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;d:\msvs8\VC\VCPackages;c:\WINDOWS\system32;c:\WINDOWS;c:\WINDOWS\System32\Wbem;c:\Program Files\Intel\DMIX;d:\mozilla-build\python25;c:\Program Files\Microsoft SQL Server\90\Tools\binn\;d:\sdks\tegra042\tools;d:\sdks\tegra042\platformlibs\bin\winxp\x86\release;d:\sdks\tegra042\3rdparty\bin\winxp\x86\release;d:\mozilla-build\python25\scripts;d:\mozilla-build\hg\bin;d:\mozilla-build\moztools\bin

LIBPATH=C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727;D:\msvs8\VC\ATLMFC\LIB

So, it ignores mozconfig vars somehow...
mozconfig vars only affect configure and make, no?
(Assignee)

Comment 40

6 years ago
I thought that cl.py inherits env...
(Reporter)

Comment 41

6 years ago
As we discusssed on our video call last week, I'm not sure that those env vars will persist through the make process. Can you try repeating each line in the mozconfig like:
export LIB="D:\msvs10\VC\LIB;D:\msvs10\VC\ATLMFC\LIB;${LIB}"
mk_add_options export LIB="D:\msvs10\VC\LIB;D:\msvs10\VC\ATLMFC\LIB;${LIB}"

The first line will persist through configure (as a shell var), the second will get set as a makefile var in client.mk.
(Assignee)

Comment 42

6 years ago
Thanks for the tip. Just have tried to do that (http://hg.mozilla.org/try/rev/674080b5a914), it failed faster this time :)

checking whether the C compiler (cl  ) works... no
*** Fix above errors and then restart with               "make -f client.mk build"
make[2]: Leaving directory `/e/builds/moz2_slave/try-w32/build'
make[1]: Leaving directory `/e/builds/moz2_slave/try-w32/build'
configure: error: installation or configuration problem: C compiler cannot create executables.
make[2]: *** [configure] Error 1
make[1]: *** [obj-firefox/Makefile] Error 2
make: *** [build] Error 2

Do you think that I should escape back slashes for mk_add_options? Or the failure is unrelated?
(Assignee)

Updated

6 years ago
Priority: P2 → P3
(Assignee)

Comment 43

6 years ago
ATM, I'm some kind of stuck with this bug.

I wanted to allow devs to select compiler from their mozconfigs (so we could use 2 compilers in try), but it doesn't seem to work.

There are other ways to go:

1) Use hardcoded env in buildbot-configs. This have to be done per branch, and require switching from one compiler to another.
2) Develop a method allowing choosing compiler by try chooser

Any other ideas?
Can we do #1 and switch just build-system for now, and play with it there?
(In reply to Rail Aliiev [:rail] from comment #43)
> ATM, I'm some kind of stuck with this bug.
> 
> I wanted to allow devs to select compiler from their mozconfigs (so we could
> use 2 compilers in try), but it doesn't seem to work.
> 
> There are other ways to go:
> 
> 1) Use hardcoded env in buildbot-configs. This have to be done per branch,
> and require switching from one compiler to another.
> 2) Develop a method allowing choosing compiler by try chooser
> 
> Any other ideas?

3) do an export MOZ_RELENG_USEMSVC2010=1 in mozconfig, and have a build script (after checkout but before build, so we can use mozconfig-find scripts from in-tree) to source the mozConfig, doing a setProperty of that, and setting win compiler based on the build Property inside buildbot.

That way it can be set by mozconfig AND be internal to buildbot.

We can even plan to drop the hack/code once we are able to drop MSVC8 (builder) support.
From some debugging on irc, it looks like there are two problems with using

  mk_add_options export LIB="D:\msvs10\VC\LIB;D:\msvs10\VC\ATLMFC\LIB;${LIB}"

The first is the mk_add_options treats each word as a separate option, and so we're ending up with something like

  export
  LIB="D:\msvs10\VC\LIB;D:\msvs10\VC\ATLMFC\LIB;${LIB}"

in .mozconfig.mk.

The second problem is that make preserves quotes around variable values. So LIB=PATH is different than LIB="PATH". We should try using this format:

  mk_add_options "export LIB=D:/msvs10/VC/LIB;D:/msvs10/VC/ATLMFC/LIB;${LIB}"
(Assignee)

Comment 47

6 years ago
I tried the following variants:

========================================================
mk_add_options "export LIB=D:\msvs10\VC\LIB;D:\msvs10\VC\ATLMFC\LIB;${LIB}"

result:
    export LIB=D:\1msvs10\1VC\1LIB;D:\1msvs10\1VC\1ATLMFC\1LIB;D:\1msvs10\1VC\1LIB;D:\1msvs10\1VC\1ATLMFC\1LIB;D:\11msvs10\11VC\11LIB;D:\11msvs10\11VC\11ATLMFC\11LIB;D:\11msvs10\11VC\11LIB;D:\11msvs10\11VC\11ATLMFC\11LIB;D:\11sdks\11v7.0\11\11lib;D:\11msvs8\11VC\11ATLMFC\11LIB;D:\11msvs8\11VC\11LIB;D:\11msvs8\11VC\11PlatformSDK\11lib;D:\11msvs8\11SDK\11v2.0\11lib;;D:\11mozilla-build\11\11atlthunk_compat;d:\11sdks\11dx10\11lib\11x86

========================================================

mk_add_options "export LIB=D:\\msvs10\\VC\LIB;D:\\msvs10\\VC\\ATLMFC\\LIB;${LIB}"

result:
    export LIB=D:\1msvs10\1VC\1LIB;D:\1msvs10\1VC\1ATLMFC\1LIB;D:\1msvs10\1VC\1LIB;D:\1msvs10\1VC\1ATLMFC\1LIB;D:\11msvs10\11VC\11LIB;D:\11msvs10\11VC\11ATLMFC\11LIB;D:\11msvs10\11VC\11LIB;D:\11msvs10\11VC\11ATLMFC\11LIB;D:\11sdks\11v7.0\11\11lib;D:\11msvs8\11VC\11ATLMFC\11LIB;D:\11msvs8\11VC\11LIB;D:\11msvs8\11VC\11PlatformSDK\11lib;D:\11msvs8\11SDK\11v2.0\11lib;;D:\11mozilla-build\11\11atlthunk_compat;d:\11sdks\11dx10\11lib\11x86

========================================================
mk_add_options "export LIB=D:\\\\msvs10\\\\VC\\\LIB;D:\\\\msvs10\\\\VC\\\\ATLMFC\\\\LIB;${LIB}"

result:
    export LIB=D:\1\1msvs10\1\1VC\1\1LIB;D:\1\1msvs10\1\1VC\1\1ATLMFC\1\1LIB;D:\1msvs10\1VC\1LIB;D:\1msvs10\1VC\1ATLMFC\1LIB;D:\11\11msvs10\11\11VC\11\11LIB;D:\11\11msvs10\11\11VC\11\11ATLMFC\11\11LIB;D:\11msvs10\11VC\11LIB;D:\11msvs10\11VC\11ATLMFC\11LIB;D:\11sdks\11v7.0\11\11lib;D:\11msvs8\11VC\11ATLMFC\11LIB;D:\11msvs8\11VC\11LIB;D:\11msvs8\11VC\11PlatformSDK\11lib;D:\11msvs8\11SDK\11v2.0\11lib;;D:\11mozilla-build\11\11atlthunk_compat;d:\11sdks\11dx10\11lib\11x86

========================================================
mk_add_options "export LIB=D:/msvs10/VC/LIB;D:/msvs10/VC/ATLMFC/LIB;${LIB}"

result:
    export LIB=D:/msvs10/VC/LIB;D:/msvs10/VC/ATLMFC/LIB;D:\1msvs10\1VC\1LIB;D:\1msvs10\1VC\1ATLMFC\1LIB;D:/msvs10/VC/LIB;D:/msvs10/VC/ATLMFC/LIB;D:\11msvs10\11VC\11LIB;D:\11msvs10\11VC\11ATLMFC\11LIB;D:\11sdks\11v7.0\11\11lib;D:\11msvs8\11VC\11ATLMFC\11LIB;D:\11msvs8\11VC\11LIB;D:\11msvs8\11VC\11PlatformSDK\11lib;D:\11msvs8\11SDK\11v2.0\11lib;;D:\11mozilla-build\11\11atlthunk_compat;d:\11sdks\11dx10\11lib\11x86

========================================================

All of them failed. I tried to use mk_add_options before and after export, neither worked...
(Reporter)

Comment 48

6 years ago
I have one more variant for you to try:

mk_add_options "export LIB=/d/msvs10/vc/lib:/d/msvs10/vc/atlmfc/lib:${LIB}"

(msys style paths)
(Assignee)

Comment 49

6 years ago
Just got try builds for this ugly mozconfig:

=======
export LIB=/d/msvs10/vc/lib:/d/msvs10/vc/atlmfc/lib:`echo $LIB | sed  -e 's,\\(\\w\\):\\\\,/\\1/,' -e 's,\\\\,/,g' -e 's,;,:,g'`
export LIBPATH=/d/msvs10/vc/lib:/d/msvs10/vc/atlmfc/lib:`echo $LIBPATH | sed  -e 's,\\(\\w\\):\\\\,/\\1/,' -e 's,\\\\,/,g' -e 's,;,:,g'`
export PATH=/d/msvs10/VSTSDB/Deploy:/d/msvs10/Common7/IDE/:/d/msvs10/VC/BIN:/d/msvs10/Common7/Tools:/d/msvs10/VC/VCPackages:${PATH}
export INCLUDE=/d/msvs10/vc/include:/d/msvs10/vc/atlmfc/include:`echo $INCLUDE | sed  -e 's,\\(\\w\\):\\\\,/\\1/,' -e 's,\\\\,/,g' -e 's,;,:,g'`
export WIN32_REDIST_DIR=/d/msvs10/VC/redist/x86/Microsoft.VC100.CRT

mk_add_options "export LIB=$LIB"
mk_add_options "export LIBPATH=$LIBPATH"
mk_add_options "export PATH=$PATH"
mk_add_options "export INCLUDE=$INCLUDE"
mk_add_options "export WIN32_REDIST_DIR=$WIN32_REDIST_DIR"

=======

I think, to be safer values should be quoted for both cases (export LIB="..."; mk_add_options "export LIB=\"$LIB\""; the latter may need \\" or something uglier :) ).

Could someone validate the binaries?

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/raliiev@mozilla.com-e3437becf5d6/try-win32/
(Assignee)

Comment 50

6 years ago
BTW, the logs will be available soon. See https://tbpl.mozilla.org/?tree=Try&rev=e3437becf5d6 for the details.
There's nothing obviously wrong (the build has the right CRT in it, it starts up, etc).
(Assignee)

Comment 52

6 years ago
I managed to get rid of ugly sed hacks and set LIB, LIBPATH and INCLUDE variables explicitly.
opt and debug builds passed without any problems. However, debug build doesn't contain ms*100.dll libs and doesn't start. I don't think that this should be a stopper for this bug.

https://tbpl.mozilla.org/?tree=Try&rev=0687af5c3ea0
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/raliiev@mozilla.com-0687af5c3ea0/

mozconfig patch incoming.
(Assignee)

Comment 53

6 years ago
Created attachment 573776 [details] [diff] [review]
vs2010-mozconfig

Example usage:

. $topsrcdir/browser/config/mozconfigs/win32/vs2010-mozconfig
Attachment #573776 - Flags: review?(ted.mielczarek)
(Reporter)

Comment 54

6 years ago
(In reply to Rail Aliiev [:rail] from comment #52)
> opt and debug builds passed without any problems. However, debug build
> doesn't contain ms*100.dll libs and doesn't start. I don't think that this
> should be a stopper for this bug.

This is the correct behavior. The debug CRT is non-redistributable, so we can't ship it in our packages. We'll have to get it installed on the test slaves like we did for the VC8 CRT in bug 562459.
(Reporter)

Comment 55

6 years ago
Comment on attachment 573776 [details] [diff] [review]
vs2010-mozconfig

Review of attachment 573776 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for trying so many variants to find something that worked! That was super helpful.
Attachment #573776 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 573776 [details] [diff] [review]
vs2010-mozconfig

Landed on m-c in a DONTBUILD changeset: http://hg.mozilla.org/mozilla-central/rev/13590cb94eab
Attachment #573776 - Flags: checked-in+
(Assignee)

Comment 57

6 years ago
The package has been deployed to the production build slaves as well (except loaned, disabled, ref images). All done here!
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Awesome.  Thanks Rail.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.