win32 fails to build using cygwin make 3.80 "unable to find"

RESOLVED FIXED in mozilla1.5beta


Build Config
15 years ago
13 years ago


(Reporter: david avery, Assigned: (default assignee for unassigned bugs. does not receive bugmail))


Windows 2000

Firefox Tracking Flags

(Not tracked)



(2 attachments, 1 obsolete attachment)

12.60 KB, patch
Daniel (Leaf) Nunes
: review+
Brian Ryner (not reading)
: superreview+
Details | Diff | Splinter Review
2.62 KB, patch
Details | Diff | Splinter Review


15 years ago
cygwin has moved to make-3.8.0 whic fails trying to build mozilla. the problem
is they defaulted the make mode to --win32. Failure is:

unable to find in obj-i586-pc-msvc

which looks like a VPATH failure

Comment 1

15 years ago
fix summary
Summary: cygwin make 3.8.0 will not build mozilla → win32 fails to build using cygwin-perl-2.8.x
Summary: win32 fails to build using cygwin-perl-2.8.x → win32 fails to build using cygwin make 3.80

Comment 2

15 years ago
daa: is there a way to "un-default" the make mode? I can't seem to find anything
in "man make" about the --win32 switch you mention.
Severity: blocker → normal
Summary: win32 fails to build using cygwin make 3.80 → win32 fails to build using cygwin make 3.80 "unable to find"

Comment 3

15 years ago
The problem is not that the MAKE_MODE defaults to --win32 when building under a
dos prompt.  The problem is that make no longer auto-translates the paths given
to VPATH into a native cygwin path.  Apparently, this was a bug.  See .

Comment 4

15 years ago
I do not see a quick fix for this.  

The obvious solution is to just make VPATH & srcdir use native cygwin paths.
(Note that both VPATH & srcdir are set from the same @srcdir@ variable.) 
Unfortunately, this causes a problem for native win32 tools which do not use the
cygwin-wrapper script, like cl or mingw gcc, as some of the optional arguments
(e.g. include paths) also use $(srcdir) .  To get around that problem, we would
need to use the cygwin-wrapper script every time we ran the compiler (as we do
for NSPR & LDAP) which would increase the build times about around 8% based upon
the numbers from bug 141834.  We could drop that number a bit by applying the
patch which has been rotting over in bug 206643.

Alternatively, we could modify the make-makefile script and each of the 1000+
Makefiles to use a different variable (ie, not @srcdir@) to set VPATH. This will
lead to us using the native cygwin paths for VPATH but using the native dos
paths for srcdir & topsrcdir.  I'm not sure how much hacking of the
make-makefile script would be required for that.  Touching each of the
Makefile.ins, while trivial, isn't something I'd look forward to doing.
Severity: normal → critical

Comment 5

15 years ago
Created attachment 128440 [details] [diff] [review]

This patch:
* makes us use native cygwin paths for srcdir & VPATH
are called using the CYGWIN_WRAPPER
* requires that the cygwin-wrapper has proper permissions (ie. executable) so
that we dependencies upon tools which use the wrapper still work (e.g.
* Removes the _NO_AUTO_VARS mess
* Replaces the multiple $(shell cygpath) calls with a $(if) to make sure that
win32 builds always use the full path to the source file (bug 141834)

The increased build time was no where near as bad as I thought it would be. 
This is a completely different machine though.	
Pre-patch  3 hr 25 min
Post-patch 3 hr 31 min


15 years ago
Attachment #128440 - Flags: review?(leaf)


15 years ago
Attachment #128440 - Flags: superreview?(bryner)

Comment 6

15 years ago
Comment on attachment 128440 [details] [diff] [review]

One thing I forgot to mention about this patch: You will need to do a 'make 
distclean' after applying the patch and build from scratch. Otherwise, the
existing Makefiles will have the wrong path for VPATH and things will fail.
Comment on attachment 128440 [details] [diff] [review]

As I discussed with cls today, this breaks MSVC builds in a few different ways.
Attachment #128440 - Flags: superreview?(bryner) → superreview-


15 years ago
Attachment #128440 - Flags: review?(leaf)

Comment 8

15 years ago
Created attachment 129083 [details] [diff] [review]

This patch should fix the problems bryner mentioned.
* Call AS, LD & MKDEPEND using the wrapper
* Makes dependencies work again by removing the invalid dos pathname from the
.pp file
* Turns on DEPENDENT_LIBS for mingw
* Fixes the DEPENDENT_LIBS problem by creating a dummy header to be used by
Attachment #128440 - Attachment is obsolete: true


15 years ago
Attachment #129083 - Flags: superreview?(bryner)
Attachment #129083 - Flags: review?(leaf)

Comment 9

15 years ago
Comment on attachment 129083 [details] [diff] [review]

Attachment #129083 - Flags: review?(leaf) → review+
Created attachment 129200 [details] [diff] [review]
patch to fix midl

In order for midl-generated files to build, you need to add MIDL to the list of
programs run with $(CYGWIN_WRAPPER) in, and also apply this patch.
Comment on attachment 129083 [details] [diff] [review]

>@@ -641,6 +619,33 @@
>+ifneq (,$(strip $(DEPENDENT_LIBS)))
>+# This much match value in nsIGenericFactory.h

I assume this should be "must match".

sr=bryner with that change and the fix for midl (though I should note that this
seems to slow the build down on my machine more than I'd hoped).
Attachment #129083 - Flags: superreview?(bryner) → superreview+

Comment 12

15 years ago
bryner:  Are things faster if you build with the latest patch in bug #206643
(major performance improvement in cygwin-wrapper)?  I would be curious to know
if others get substantially better build times as I do (mind you, I'm using
"antiquated" hardware--PII266 with 256MB).

Comment 13

15 years ago
Patches have been checked in.
Last Resolved: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.5beta
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.