Regarding an instructions update to make everything work on a vanilla box, it didn’t happen over Christmastime; it will happen sometime in the next month.

As per the fix for bug 241528, you actually can build the IE profile migrator now.
In your build script, cygwin\bin must precede WINDOWS\system32 because cygwin’s find.exe has to override the one in system32. Otherwise, the build won’t package properly and, because of a recent checkin, actually break when it tries to package extensions like inspector and reporter.
I’ve honestly never had problems with an objdir build (under the “Cons” section, you noted that such a thing might cause trouble), but if you want to keep the warning I guess that’s fine…

[Ooh, thanks for letting me know about the second one! I last did a compile several weeks ago and just tried yesterday to get an error which is probably a result of that, so you've saved me some effort on resolving that (assuming it works; I haven't restarted the build to see). The way I currently have the path set up in what I'm using on my machine (which might not match what's here exactly because I haven't had a chance to test everything here recently) means that doing this could cause cygwin's perl to override the ActiveState perl, so I still will need to resolve that before I re-publish the instructions. As for the third, it was reputedly fixed quite a while back, and as I only rarely update these instructions (almost always when I can personally test that it all works) it's hung around a while. The first I may or may not have mentioned in a recent comment; look back and see ;-).]

Response to
Comment by Robert Claypool — 15.08.05 @ 20:35
Comment by Victor Ronin — 29.08.05 @ 10:41

I too had the problem with the lib.exe returning error 5.
I have VC6 installed (but use free compiler as in the example) and noticed that if I ran vcvars.bat and lib.exe manually (copy & pasting arguments) it worked.
With the described setup it seems like masm32\bin\lib.exe is used. So I
1 Renamed lib.exe in that directory (…masm32\bin\lib.exe -> …\masm32\bin\lib.exe.old)
2 Created a bat file …masm32\bin\lib.bat containing
echo libscript
call “c:\Program Files\Microsoft Visual Studio\VC98\Bin\VCVARS32.BAT”
lib %*
3 Started a cygwin. cd to …masm32\bin\
ln -s lib.bat lib

And rerun the make.

At least it compiled longer this time.

Best regards,
Marcus

Gud start!. Just have a small request: -

AT THE BOTTOM OF THE BUILD INSTRUCTIONS AND THE MAIN UPDATES AFTER THAT, PLEASE PUT A SENTENCE THAT READS LIKE “TESTED TO BE WORKING FINE AS OF ” AND “LAST UPDATED ON “.

This shall actually help people like me who visit your site regularly and have to reset their build environment frequently because of windows reinstallations etc…

(sorry for the caps. just wanted to be noticed.)

Keep up the good work.

[I notice everything that's posted because I get emails on moderated and posted comments; the problem is that I don't have a lot of time, and responses to comments are low on the list of priorities. I added Last Updated note to the top of the doc, although it's not going to be very helpful yet. Look for a real update around Christmas or so.]

[The instructions are intended to work with the "latest" code, so I can't provide a link to source downloads. The patch should be readable in a text editor; try manually applying it if you really need to do so. Keep in mind, tho, that the import/export patch is no longer needed, at least on trunk (I haven't tried compiling branch code with my setup), so try without the patch first.]

D:\moz\mozilla>make -f client.mk build
cd /cygdrive/d/moz/mozilla
/cygdrive/d/moz/mozilla/configure
loading cache ./config.cache
checking host system type… i686-pc-cygwin
checking target system type… i686-pc-cygwin
checking build system type… i686-pc-cygwin
checking for gcc… cl
checking whether the C compiler (cl ) works… no
configure: error: installation or configuration problem: C compiler cannot create executables.
*** Fix above errors and then restart with “make -f client.mk build”
make: *** [/cygdrive/d/moz/mozilla/Makefile] Error 1

I had this one too. It was caused by having run the wrong “link” - make sure your PATH variable contains the cygwin/bin *after* your MSVC directory!

I currently just got a trunk (debug, dynamically-linked, shared) Firefox build to compile using the free MS Toolkit and your instructions above. I’d love it if we could include some of these instructions in a page in the new DevMo build documentation.
Here are some notes on what I had to do to get the build to complete.

1.) Alter the buildsetup.bat file, updating directories, changing the order of PATH, LIB, & INCLUDE, and making it easier to use non-default directories. Here is what my file looks like:

REM — changes these to whatever the correct paths for your installation are —

SET HOME=C:\cygwin\home\James
SET MOZ_TOOLS=C:\moz\moztools
SET GLIB_PREFIX=C:\moz\vc71
SET LIBIDL_PREFIX=C:\moz\vc71

SET PSDK=C:\Program Files\Microsoft Platform SDK
SET VCTK=C:\Program Files\Microsoft Visual C++ Toolkit 2003
SET VSDN=C:\Program Files\Microsoft Visual Studio .NET 2003
SET DNSDK=C:\Program Files\Microsoft.NET\SDK\v1.1
SET DNFW=C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322
SET MASM=C:\Program Files\masm32 (I moved this after install from C:\masm32)
SET CYGWIN=C:\cygwin

REM — set up environmental variables —

SET PATH=%GLIB_PREFIX%;%GLIB_PREFIX%\bin;%VCTK%\bin;%PSDK%\Bin;%DNSDK%\Bin;%VSDN%\Common7\IDE;%PSDK%\Bin\Win64;%PSDK%\redist\win64;%DNFW%;%MASM%\BIN;%MOZ_TOOLS%\bin;%CYGWIN%\bin;%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\wbem

SET INCLUDE=%VCTK%\include;%PSDK%\include;%DNSDK%\include;%VSDN%\Vc7\include;%PSDK%\include\crt;%MASM%\INCLUDE;%PSDK%\include\atl;%PSDK%\include\mfc

SET LIB=%VCTK%\lib;%PSDK%\Lib;%DNSDK%\Lib;%VSDN%\Vc7\lib;%MASM%\LIB;%PSDK%\Lib\IA64;%PSDK%\Lib\IA64\mfc

2.) had to set NO_MFC=1 (as in Comment 4)

3.) When I got the error about not having the file atlthunk.lib, I tried to build it myself as suggested in Comment 10. I installed the relevant PSDK sources and ran ‘nmake /f atl.mak’, but nmake just gave me the same error about atlthunk.lib not being found! I did some web searching, and according to http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=64509, there is a different implementation of ATL (Active Template Library) in the PSDK than in Visual Studio, and the one in Visual Studio doesn’t require atlthunk.lib, which apparently is not available to anyone outisde of Microsoft. So IIUC, we have to either get the atl implementation in Visual Studio or comment out the “#pragma include atlthunk.lib” line of atlbase.h (as in Comment 4), which I did.

4.) Also, due to a just-fixed bug (https://bugzilla.mozilla.org/show_bug.cgi?id=241528), which you filled, the disable-ie-migrator patch is no longer needed.

5.) No trouble with midl, cygwin perl, or make 3.80. No need to alter any makefiles (as in end of comment 4). Fortunately, also no error messages about nspr4, “unresolved external symbol”, or missing files (once I got my PATH, LIB, & INCLUDE right).

6.) Comment 3 does seem to be right about the minium PSDK components that need to be downloaded and installed.

7.) After mybuild completed, I could run firefox.exe (in objdir\dist\bin), but with plenty of error messages in the backgroup and Firefox soon froze up. I also created an installer, but it doesn’t work.

[I recently - just for kicks - decided to try building trunk Firefox with the Windows setup I had from when things weren't working. Oddly enough, it worked after only one hiccup! Some combination of changes I'd made to the build setup combined with changes to the Mozilla source code itself made everything work correctly. Unfortunately I don't have time quite yet to update the instructions to get a working build setup due to classes, so the update will have to wait until at least Christmas.

In response to the information you posted in #3, I also did some searching and came to the same conclusions. It may be editing the platform SDK, but if the change can't possibly make anything else that might be built break, I have no compunctions about recommending it.

To anyone else interested in this, I think there's enough information in the article and the comments to successfully get a working build environment. The information's fragmented and sometimes misleading, true, but there's enough to do it if you really, really want to do so. I will update this when I have time, but I don't right now, so feel free to comment and discuss things if you need help getting anything working. When I update the page I also intend to split comments out into separate pages to make it easier to get the information without being distracted by large number of comments.

One last - sorry that I've been a bit slow about approving comments lately; real life has been a real time suck. Anyone who's posted previously should be able to post without delays, tho, so hopefully that'll at least mitigate the problem. I'll try to keep on top of the queue a bit better in the future.]