Closed Bug 58981 Opened 24 years ago Closed 23 years ago

Converting windows build to gmake

Categories

(SeaMonkey :: Build Config, defect, P1)

Product:
SeaMonkey
Component:
Build Config
Platform:
x86
Windows 2000
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.8

People

(Reporter: cls, Assigned: cls)

References

Details

Attachments

(10 files, 6 obsolete files)

Add win32 support to configure & .c build rules
21.77 KB, patch
alecf
: superreview+
Details | Diff | Splinter Review
Patch 01
14.77 KB, patch
bryner
: review+
Details | Diff | Splinter Review
Update xpcom for win32-gmake builds
24.24 KB, patch
bryner
: review+
Details | Diff | Splinter Review
os/2 build patch
43.54 KB, patch
netscape
: review+
Details | Diff | Splinter Review
security manager patch
1.09 KB, patch
Details | Diff | Splinter Review
previous patch updated from timer & accessibility landings
294.21 KB, patch
Details | Diff | Splinter Review
Make ldap build on win32 using gnu make
6.48 KB, patch
dmosedale
: review+
Details | Diff | Splinter Review
Sync dynamic library & xpidl_module names for win32 builds
31.62 KB, patch
jag+mozilla
: superreview+
Details | Diff | Splinter Review
Make "static" build work for win32 gmake builds
11.27 KB, patch
bryner
: review+
shaver
: approval+
Details | Diff | Splinter Review
Failed build
21.53 KB, text/plain
Details 
I've been thinking about this for a couple of years now and I think I'm almost
ready to tackle it. :-) My experience with nmake is limited but from what I've
seen it's missing some features that we would find useful for our build process.
 As a result, we end up with some build features on the unix side that do not
translate well to the windows build system.  An example of this is our selective
modules build system (triggered by using --enable-modules=mod1,mod2 in
configure).  Historically, we've been adding specific targets to client.mak in
order to duplicate that functionality.  This is going to get fairly unwieldy
once we have a fully modular build.

I've been thinking about various approaches to this and I believe this is easily
doable with minimal impact.  Logic dictates that if we're going to use gmake,
then we want to reuse the existing (gmake) Makefiles that we currently use.  At
a glance, this means that we need to run configure on windows to generate the
Makefiles which involves installing sh(bash) and therefore, the cygwin posix
layer which is noticably slower than the native dos shell.  That statement is
not entirely true.  Currently, on unix, we use perl to generate the Makefiles
and speed up the process by orders of magnitude by only substituting the
variables that we need for the Makefiles, srcdir & topsrcdir.  We would still
need bash to generate the MAKEFILES list from allmakefiles.sh but that's a minor
detail that could be easily worked around by encompassing that functionality in
a perl script.  We would still need to have some sort of script to do the proper
substitutions on autoconf.mk so that we wouldn't have to completely change the
autoconf system to incorporate win32.  Finally, there is gmake itself.  On unix
and using cygwin's gmake, by default, gmake will use /bin/sh to exec the actual
commands of the Makefile.  However, the cygwin & mingw32 versions of gmake allow
you to use the standard DOS shell to exec commands which means that the majority
of the build process will not be subject to the slowdown caused by the cygwin
posix layer.  Barring any major deficiencies in mingw32's port, there should
little if any difference in the build speed from our current nmake builds.

IMO, the hardest part about the conversion (besides developer acceptance) will be:

1) Merging config.{mk,mak} & rules.{mk,mak} .  Mainly, ifdefing off any /bin/sh
specific pieces
2) writing the configure.win perl script ( to do substitutions on autoconf.mk &
Makefiles ... the need for actual feature tests is debatable)
Status: NEW → ASSIGNED
Adding a dependency upon 58804 since that's currently where all of the work is
actually being done.  win32 nspr autoconf is just about done.  The major changes
are in the tree, it just needs to be heavily tested.
Depends on: 58804
"developer acceptance" probably turned into "developer apathy" - until now when
you start hitting tree. But you can make people accept (or flee!) by flogging
them hard and repeatedly. I think the thing you are going to need to focus on is
developer education. There are a lot of stupid little win32 specific build flags
and defines that people are going to want to set on a per-directory basis. We
are going to need to know how to do stuff - and have assurance that other
platforms won't get whacked.
Target Milestone: --- → mozilla0.9
Target Milestone: mozilla0.9 → mozilla1.0
Target Milestone: mozilla1.0 → mozilla0.9.8
windows gmake lands in < 8 weeks (0.9.8) and it's not showing up on
http://komodo.mozilla.org/planning/branches.cgi ?  That's going to be quite a
whack, is there a branch tag where this can be tried out?
Oh, people actually pay attention to that? ;)  No, it's not landing in 8 weeks.
 I plan on adding win32 support to the current unix system piecemeal.  If I can
get all the necessary pieces in by 0.9.8, then we can talk about switching over
by 0.9.9.  Otherwise, it'll just be an unsupported feature.

Piece zero:  Initial win32 support.  Allows configure to detect win32 in the
same fashion as NSPR.  Updated rules.mk enough to compile .c files
(specifically dbm & js).  After applying the patch, you'll need to run autoconf
from a bash or tcsh prompt or provide the full path from cmd.exe, ie sh
\cygwin\bin\autoconf .

sh configure --enable-standalone-modules=dbm,js
make
make distclean

netscape's gmake (which uses shmsdos) works too except it dies at the very end
of the 'distclean' as it can't handle the pipe in this rule:
cat unallmakefiles.sh | xargs rm -f
Comment on attachment 59967 [details] [diff] [review]
Add win32 support to configure & .c build rules

awesome! sr=alecf

Though a few things like the NO_GCC_PIPE thing, I wonder if we could have some
global USING_GCC which determines the gcc-specific options..so we wouldn't have
to hard-code it for win32
Attachment #59967 - Flags: superreview+
That's what GNU_CC & GNU_CXX are for.  I just wanted to skip the option check
completely for that case, which is moot now since it's going away (bug 81031).

I'm trying to grasp what this patch achieves.
Does it enable to get rid of
 
* netscape gmake (shmsdos)
* cygwin
* nmake
* ms c++ compiler
* makefile.win(s)

From my point of view the combination of

* gmake & ms c++ compiler
* gmake & mingw32

does make sense. That would eliminate the
makefile.win(s), the netscape gmake and
cygwin as a prerequisite. Am I missing
something?
The first patch achieves the goal of getting win32 recognized by the unix build
system and compiling basic C programs.  That's it.   No build requirements have
been eliminated at this point.
Attached patch Patch 01 — — Splinter Review 
This patch:
* Allows win32 to build from objdirs
* Adds LIB_PREFIX to the build.  LIB_PREFIX is typically set to either 'lib' or
'' depending upon whether the platform expects libraries to be in the form
libfoo.$(LIB_SUFFIX) or foo.$(LIB_SUFFIX)
* Reads MOZ_TOOLS at configure time to determine LIBIDL_CFLAGS & LIBIDL_LIBS
* Moves MOZ_DEBUG_LDFLAGS logic into config.mk
* Fixes problem with ldap being configured for standalone modules even when not
specified
* Added rules to let win32 build PROGRAMS & SIMPLE_PROGRAMS
This patch:
* Syncs xpcom Makefile.ins with makefile.win counterparts.  In particular,
win32 requires that the EXPORT_*_API & _NS_IMPL_* defines be used when
compiling xpcom while most unix systems apparently don't care.
* Adds win32 xpcom Makefile.ins to allmakefiles.sh
* Updates standalone xpcom dirs list
Priority: P3 → P1
Comment on attachment 60974 [details] [diff] [review]
Patch 01

r=bryner
Attachment #60974 - Flags: review+
Comment on attachment 60975 [details] [diff] [review]
Update xpcom for win32-gmake builds

r=bryner
Attachment #60975 - Flags: review+
Comment on attachment 61052 [details] [diff] [review]
Sync intl/ makefiles for win32-gmake build

sr=alecf though it seems like we need an easy way of adding
-DWIN32_LEAN_AND_MEAN, because a bunch of dirs use it.

Also, are we sure we need the -D__STDC__ or might that just be old makefile
cruft?
Attachment #61052 - Flags: superreview+
Comment on attachment 61053 [details]
mozilla/intl/locale/src/windows/Makefile.in

sr=alecf
Attachment #61053 - Flags: superreview+
win32's -DWIN32_LEAN_AND_MEAN isn't that much different than Linux's
-D_BSD_SOURCE which a number of Makefile.ins also need.  I don't see the need
for a special makefile flag just to add that define.  A quick grep showed that
roughly half of the makefile.wins with _OBJS also used that define.  We could
add it to the global win32 options but I don't know how that'd affect the build.

I have no idea if the __STDC__ is still need.  I was kinda surprised that
wouldn't have been taken care of by msvc.
Attached patch os/2 build patch — — Splinter Review 
This patch includes changes necessary to build OS/2 using the win32 changes. 
Also finished some of the LIB_PREFIX substitution.
Patch to security/manager in order to build on OS/2.  Requires changes in bug
114748.
I'm working on bug 23560 "add Version tab on win32 DLLs/EXEs when viewing
Properties". When that is complete, will there be any problem adapting this the
gmake build process? gmake on win32 will still use win32 resource files and
rc.exe, right? Otherwise, how would gmake put in things like win32 cursors and
version resources?

Daa on IRC said that there can be rules for that. I had assumed (probably
incorrectly) that gmake on all platforms used the same resource files. Does your
gmake system use different resources for each platform?
Also, will there be an ability to build browse info? (.sbr files)
netdemon: I don't think that any other platform besides windows uses resource
files (I know for sure that Linux doesn't).
Attached patch everything else (sans ldap) (obsolete) — — Splinter Review 
This patch:
* Adds win32 support to the rest of the tree (except ldap)
* Requires cygwin make or Netscape's gmake using a bourne compatible shell
* Assumes that we're using unix shared library names except in places where a
.def file said otherwise.  Bug 65520 is also tackling this issue.

shmsdos.exe cannot handle pipes or stdio redirection which we use in a handful
of our unix build rules (notably dependencies & the make jar script), so we'll
need to drop Netscape's gmake and require cygwin's gmake to build.

Between ldap piggybacking off of the nspr build system on the unix side and
using a completely separate nmakefile on the win32 side,  I ran into nothing
but problems trying to get ldap to compile for win32 using the unix makefiles. 
bug 75028 may need to be resolved before we can make any head way on this.  For
now, --disable-ldap.

xpinstall/wizard/windows/setuprsc refuses to create an import library for me
which breaks the build because the default rules expect that lib to exist.  I'm
probably just missing a link flag since the nmake build works fine there.  For
now, it's commented out of the build.

For dependencies, we use config/mkdepend rather than makedep.exe.  makedep was
hardcoding all caps dos paths into the dep files which seemed to confuse gmake.
 

You can use mozconfig files with the build.  Just set MOZCONFIG in your env and
you're ready to go.  You can even use client.mk to pull the tree.

On my laptop, the optimized gmake & nmake clobber (no dep stage) builds took
almost approximately the same amount of time.  They were within a minute of
each other.    So on W2k, at least, there is no slowdown from using the cygwin
tools.
Attachment #61052 - Attachment is obsolete: true
Attachment #61053 - Attachment is obsolete: true
Attachment #61054 - Attachment is obsolete: true
Attachment #61063 - Attachment is obsolete: true
Attachment #61066 - Attachment is obsolete: true
OS/2 uses resources files, and we have added some resource file support into 
rules.mk already.

We handle linking them a little different. I believe windows links them 
directly to the executable during the link step, while we use a resource 
compiler to "bind" them after the EXE or DLL is built.
The mega patch 2 days ago.  To test this, you still need to apply the xpidl
patch from bug 114257.  There's also a tinderbox setup on the Ports page.  (If
anyone's wondering, it does use the standard unix tinderbox script.)  It looks
slightly unpolished (still uses the default windows icon images) but the build
should be to the point where people can start hammering on it and giving
feedback (hint, hint).

While setting up the tinderbox, I discovered that you can't call configure using
a  full path.  If configure gets called with the dos path, then some cygwin
progs (like sed) get confused by the drive letter thing .  If you call it using
the full cygwin path, then cl.exe gets confused by the /cygdrive/c/ path.  I'm
open to suggestions as to how to properly fix this one.  For the tinderbox, I'm
bypassing the fullpath problem by setting --srcdir to a relative path in mozconfig.

On the build tools front, we're going to have additional dependencies.  I had
findutils installed, which provides some tools that we'll need (like find &
xargs).  And I was using cygwin perl.  I don't think activestate perl should
have any problem with the scripts as most of them are XP but I haven't tested it
yet.

netdemon:  Unless the patch you contribute uses some nmake extension, I don't
believe there would be a problem adapting those rules to the gmake build.

I downloaded the 0.9.7 source code.

From a bash I did:

$ cd /cygdrive/d/mozilla/source/mozilla
$ autoconf

From cmd.exe I did:

$ sh configure --disable-ldap

[Why is the generation of makefiles so slow?]

$ make

I set the PATH to c:\gnu\cygwin\bin and $MOZ_TOOLS\bin. 
Therefore it found perl.exe and make.exe in cygwin\bin
whereas it found nsinstall,exe, libidl.dll and 
the other g*.dll in MOZ_TOOLS\bin. Obviously one 
doesn't need the activestate perl.

My impression was that the build was running at the
same speed as a nmake build. I would have measured the
time exactly for a whole build but couldn't because
the make died here:

make[2]: Entering directory `/cygdrive/d/mozilla/source/mozilla/xpcom/tests'
../../config/rules.mk:789: target `PropertiesTest.exe' given more than once in 
the same rule.
make[2]: *** No rule to make target `windows/Makefile.in', needed by 
`windows/Makefile'.  Stop.
make[2]: Leaving directory `/cygdrive/d/mozilla/source/mozilla/xpcom/tests'

Do I need to apply patches from bug 114257? Do I need to --disable-tests? 
Thanks.

Sorry, the full build will not work with the 0.9.7 source code.  The majority of
the changes landed after 0.9.7 branched.  Any nightly source tree since the
2001/12/19 + the patch from bug 114257 should work.

By default, configure runs an individual sed command for each of the scores of
variables substituted in the makefiles.  It does this regardless of whether that
particular makefile needs that variable.  The number of Makefiles x the number
of Makefile variables == slow Makefile generation.

To speed things up quite a bit, the toplevel configure script uses a perl helper
script to generate the Makefiles if they only contain @srcdir@ & @topsrcdir@
variables, which is about 98% of the Makefiles.  The NSPR & LDAP build systems
do not use this script so their makefile generation is noticably slower.


Ok, I downloaded the 28 dec 2001 nightly source code tar ball.

On WinNT 4.0 SP 6 with MOZ_DEBUG=1 I ran:

$ nmake /f client.mak build_all

start : Sat Dec 29 06:24:11  2001
stop  : Sat Dec 29 09:21:40  2001

I deleted mozilla/** and installed the tar ball again.

I applied the patch from bug

After running autoconf I did:

$ make 

The build died here

EVIEW=1 -DMOZ_REFLOW_PERF=1 -DMOZ_REFLOW_PERF_DSP=1  nsGfxFactory.cpp
nsGfxFactory.cpp
rm -f gfx2.dll
link /NOLOGO /DLL /OUT:gfx2.dll /PDB:.pdb /SUBSYSTEM:WINDOWS /MAP:.map /MAPINFO:
LINES  gfxImageFrame.obj nsGfx
Factory.obj     /DEBUG /DEBUGTYPE:CV       ../../dist/lib/xpcom.lib ../../dist/l
ib/nspr4.lib ../../dist/lib/pl
c4.lib ../../dist/lib/plds4.lib  kernel32.lib user32.lib gdi32.lib winmm.lib 
wsock32.lib advapi32.lib
   Bibliothek gfx2.lib und Objekt gfx2.exp wird erstellt
gfxImageFrame.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec
(dllimport) public: void __thi
scall nsRect::SetRect(int,int,int,int)" (__imp_?SetRect@nsRect@@QAEXHHHH@Z)
gfxImageFrame.obj : error LNK2001: Nichtaufgeloestes externes Symbol "__declspec
(dllimport) public: __thiscall
 nsRect::nsRect(int,int,int,int)" (__imp_??0nsRect@@QAE@HHHH@Z)
gfx2.dll : fatal error LNK1120: 2 unaufgeloeste externe Verweise
make[3]: *** [gfx2.dll] Error 96
make[3]: Leaving directory `/cygdrive/d/mozilla/source/mozilla/gfx2/src'
make[2]: *** [libs] Error 2
make[2]: Leaving directory `/cygdrive/d/mozilla/source/mozilla/gfx2'
make[1]: *** [tier_9] Error 2
make[1]: Leaving directory `/cygdrive/d/mozilla/source/mozilla'
make: *** [default] Error 2

"unaufgeloeste externe Verweise" means: "unresolved external references".

Any idea how to proceed? Thanks.
Since 'nsRect' seems to be defined in 'gkgfx.lib' I added it
to 'EXTRA_DSO_LDOPTS' in the Makefile. Due to the fact that
it is also needed in linking processes while being beneeth 
the 'modules/libpr0n' directory I added 

$(DEPTH)/dist/lib/gkgfx.lib 

to 

MOZ_COMPONENT_LIBS 

in config.mk. Unfortunately if I start the build from
scratch again, it fails in linking xpcom since 'gkgfx'
isn't available at that point of the build.

Any hint? Thanks.
I also needed to add

$(DEPTH)/dist/lib/DebugRobot.lib
	
to OS_LIBS (which is defined if OS_ARCH==WINNT)

in mozilla/webshell/tests/viewer/Makefile.in

because of this:

link /NOLOGO /OUT:viewer.exe /PDB:.pdb nsWinMain.obj JSConsole.obj 
nsWidgetSupport.obj nsBaseDialog.obj nsFind
Dialog.obj nsXPBaseWindow.obj nsTableInspectorDialog.obj 
nsImageInspectorDialog.obj nsPrintSetupDialog.obj nsB
rowserWindow.obj nsEditorMode.obj nsThrobber.obj nsViewerApp.obj 
nsWebCrawler.obj nsWebBrowserChrome.obj nsWin
dowCreator.obj   /DEBUG /DEBUGTYPE:CV       -SUBSYSTEM:CONSOLE 
windows/viewer_windows_s.lib ../../../dist/lib/
widgetsupport_s.lib ../../../dist/lib/gkgfx.lib ../../../dist/lib/jsj.lib ../../
../dist/lib/xpcom.lib ../../..
/dist/lib/mozjs.lib ../../../dist/lib/nspr4.lib ../../../dist/lib/plc4.lib ../..
/../dist/lib/plds4.lib kernel3
2.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib shell32.lib 
ole32.lib oleaut32.lib oleacc.lib im
m32.lib uuid.lib comdlg32.lib
   Bibliothek viewer.lib und Objekt viewer.exp wird erstellt
nsViewerApp.obj : error LNK2001: Nichtaufgeloestes externes Symbol _DebugRobot
viewer.exe : fatal error LNK1120: 1 unaufgeloeste externe Verweise
make[4]: *** [viewer.exe] Error 96
make[4]: Leaving directory 
`/cygdrive/d/mozilla/source/mozilla/webshell/tests/viewer'

Then the next problem was located here:

nsztool.c
link /NOLOGO /OUT:nsztool.exe /PDB:.pdb 
nsztool.obj   /DEBUG /DEBUGTYPE:CV       /SUBSYSTEM:WINDOWS /MACHINE:i
386 ../../../../dist/lib/mozz_s.lib kernel32.lib user32.lib gdi32.lib winmm.lib 
wsock32.lib advapi32.lib
nsinstall -m 755 nsztool.exe ../../../../dist/bin
nsinstall nsztool.exe ../../../../dist/install
../../../../dist/install/nsztool.exe -
g ../../../../dist/install/nszip.exe ../../../../dist/install/nsinstall.
exe
make[4]: *** [libs] Error 1
make[4]: Leaving directory 
`/cygdrive/d/mozilla/source/mozilla/xpinstall/wizard/windows/nsztool'

The 'nsztool' didn't find the 'nsinstall.exe' in $(DEPTH)/dist/install because
it was neither built nor installed; it's used from the $(MOZ_TOOLS) directory.

After that the build went through and I launched 'mozilla-bin.exe' and got this:

###!!! ASSERTION: NS_ENSURE_TRUE(NS_SUCCEEDED(docLoaderFactory->CreateInstance
("view", aOpenedChannel, aLoadGr
oup, aContentType, static_cast< nsIContentViewerContainer * >(this), 0, 
aContentHandler, aViewer))) failed: '(
!((docLoaderFactory->CreateInstance("view", aOpenedChannel, aLoadGroup, 
aContentType, static_cast< nsIContentV
iewerContainer * >(this), 0, aContentHandler, aViewer)) & 0x80000000))', file 
nsDocShell.cpp, line 3650
WEBSHELL+ = 3
Looks like that link error only shows up in debug builds and I've been doing opt
builds.  I'll check in a fix for those errors.

I just checked in the debug link error fixes.  I got hung up due to a crash on
startup problem caused by building the wrong platform specific file in netwerk.
 That wasn't fun to track down.  I also added support for processing .rc files
so the builds should start looking polished again (ie has non-win32 default
icons + splash screen, etc).

I applied the patches and started the build again.
I must have done something wrong because the build
still breaks in mozilla/gfx and mozilla/modules/libpr0n .
Do the patches apply to these directories as well or
am I too impatient?
The updated source tarball that contains the debug fixes hasn't been generated
yet.  You'll need to pull from cvs or wait a couple of hrs to pull the updated
tarball.

I hacked up the ldap makefiles a bit and managed to get it to build the ldap
library.  On win32, we don't seem to build the lber library separately so I
just rolled the necessary files into ldap library.  And of course, win32 uses a
different name for the library than the rest of the platforms.
Comment on attachment 63313 [details] [diff] [review]
Make ldap build on win32 using gnu make

How about removing instead of commenting out the lines around the DIRVER
changes mozilla/directory/c-sdk/ldap/include/Makefile.in?  We've always got
cvsblame to fall back on.

Do that and get somebody to test that this won't break OS/2, and you've got
r=dmose@netscape.com.
Attachment #63313 - Flags: review+
I downloades 4 jan 2002 source code tarball.

I'm still having problems with the nsztool
(see above). Also the build failed to copy 

xpinstall/wizard/windows/setuprsc/setuprsc.h

to dist/include. Therefore the build broke in

xpinstall/wizard/windows/setup

Other than that the build was ok and the
executable ran fine.
The mapi directories (mailnews/mapi/mapiDll and mailnews/mapi/mapihook) do not
have Makefile.in's; does this belong in this bug or should I file another one?
Disregard my last question, Bug 120135 was filed for Mapi's Makefile.ins
This patch syncs the naming differences between the nmake & gmake builds since
it doesn't look like we're going to make any headway on gettng win32 & unix
builds to share the same library names (bug 65520) anytime soon.  

Of course, there are the usual handful of exceptions:
* the intermediate libraries (xpcombase_s) still use the unix names
* nsreg & mozreg are static since they are only used in 2 places
* jpeg3250 is currently static although this may change (bug 81278).
* gmake build has an embed-sample.jar instead of an embed.jar
Comment on attachment 65187 [details] [diff] [review]
Sync dynamic library & xpidl_module names for win32 builds

sr=jag
Attachment #65187 - Flags: superreview+
This should be the last of the tweaks for the Mozilla side of things.  This
patch integrates the win32 static build changes with the unix static build
system.
Comment on attachment 66397 [details] [diff] [review]
Make "static" build work for win32 gmake builds

r=bryner
Attachment #66397 - Flags: review+
Comment on attachment 66397 [details] [diff] [review]
Make "static" build work for win32 gmake builds

By the power vested in me by drivers@mozilla.org, yadda, yadda.

a=shaver for mozilla 0.9.8.
Attachment #66397 - Flags: approval+
The static build patch has been checked in on the trunk and the 0.9.8 branch. 
And that, folks, is a wrap.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Eventually, are you going to remove the Windows makefiles and have client.mak
start gmake?
just built with make on windows.  worked fine.  Great Job!!
netdemon: As I understand this, client.mak & makefile.win will be removed, and
client.mk should be used.
Also the Build documentation going to be updated on mozilla.org?
the build doc (http://www.mozilla.org/build/win32.html) was updated to reflect
the ability to build with gmake, including the change in system requirements.
When we've migrated everyone to using gmake, we'll start cvs removing any
obsolete files.
I tried it and it didn't work even though I set MOZ_TOOLS so that
MOZ_TOOLS\include had glib.h in it. I did everything I was told to. I even
re-downloaded the entire tree and nothing I try works.

I will attach my build output.
Attached file Failed build — 

    
    

    
  
netdemon: Try compiling from cmd.exe/command.com instead of cygwin... (don't use client.mk there, though. do "sh ./configure" and then "make")

    
    

    
  
Didn't work :-(

    
    

    
  
I'm going back to building with nmake. I think this bug should be reopened.

    
    

    
  
Reopen, or (prolly better results) file a new bug on the specific prob.

/be

    
    

    
  
Talking to cls, I think we hit the problem. The first time I built Mozilla in
1999, I read http://www.mozilla.org/build/win32.html and read "This batch script
will install the files into %MOZ_TOOLS%/bin. Do NOT set MOZ_TOOLS to be the
parent of your GNU tools directory." as %MOZ_TOOLS% should be set to your gnu
tools dir, which I thought was cygwin (the parent of bin). I thought it meant
don't have it in the parent of the cygwin dir. It build without a hitch, so from
then on i did it that way which didn't cause a problem until now. Therefore, I'm
removing cygwin, reinstalling it and making the moz_tools dir someting
different. Hopefully this will solve the problem. Anyway, this info might be
helpful to anyone who runs into the same problem.

    
    

    
  
Now that this Bug (58981) has landed is the branch win32-gmake-build-support
http://komodo.mozilla.org/planning/branches.cgi going to be retired?

    
    

    
  
the release builds haven't been switched over yet.

    
    

    
  
I just moved this to completed on the branch landing page.

    
    

    
  
v fixed.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: