Closed Bug 345482 Opened 17 years ago Closed 17 years ago

Build fails with GNU make 3.81

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jhenry, Assigned: benjamin)

References

Details

Attachments

(3 files, 1 obsolete file)

Band-aid patch
2.22 KB, patch
Details | Diff | Splinter Review
NSS and mozilla-driver patch to build with MSYS make 3.81
12.28 KB, patch
Details | Diff | Splinter Review
Fix abspath in gmake 3.81, rev. 2 (by Benjamin Smedberg)
5.04 KB, patch
wtc
: review+
christophe.ravel.bugs
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060721 Minefield/3.0a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060721 Minefield/3.0a1

Spun off from bug 325148.

When building on Windows XP using cygwin and Visual Studio 2005, I got the following errors. Cygwin recently began shipping GNU make version 3.81. Downgrading from 3.81 to 3.80 allows me to build normally again.

make[1]: Entering directory `/cygdrive/c/mozillaroot/firefox/security/manager'
/usr/bin/make -C /cygdrive/c/mozillaroot/mozilla/security/coreconf MAKE="/usr/bin/make -j1" -j1 CC="
/cygdrive/c/mozillaroot/mozilla/build/cygwin-wrapper cl" SOURCE_MD_DIR=c:/mozillaroot/firefox/dist D
IST=c:/mozillaroot/firefox/dist NSPR_INCLUDE_DIR=c:/mozillaroot/firefox/dist/include/nspr NSPR_LIB_D
IR=c:/mozillaroot/firefox/dist/lib MOZILLA_CLIENT=1 NO_MDUPDATE=1 NSS_ENABLE_ECC=1 BUILD_TREE=c:/moz
illaroot/firefox BUILD_OPT=1 NS_USE_GCC= NS_USE_NATIVE=1 OS_TARGET=WIN95
make[2]: Entering directory `/cygdrive/c/mozillaroot/mozilla/security/coreconf'
../coreconf/rules.mk:365: target `c' doesn't match the target pattern
../coreconf/rules.mk:406: target `c' doesn't match the target pattern
../coreconf/rules.mk:407: warning: overriding commands for target `c'
../coreconf/rules.mk:366: warning: ignoring old commands for target `c'
../coreconf/rules.mk:437: target `c' doesn't match the target pattern
../coreconf/rules.mk:438: warning: overriding commands for target `c'
../coreconf/rules.mk:407: warning: ignoring old commands for target `c'
../coreconf/rules.mk:445: target `c' doesn't match the target pattern
../coreconf/rules.mk:446: warning: overriding commands for target `c'
../coreconf/rules.mk:438: warning: ignoring old commands for target `c'
../coreconf/rules.mk:449: target `c' doesn't match the target pattern
../coreconf/rules.mk:450: warning: overriding commands for target `c'
../coreconf/rules.mk:446: warning: ignoring old commands for target `c'
../coreconf/rules.mk:464: target `c' doesn't match the target pattern
../coreconf/rules.mk:465: warning: overriding commands for target `c'
../coreconf/rules.mk:450: warning: ignoring old commands for target `c'
../coreconf/rules.mk:468: target `c' doesn't match the target pattern
../coreconf/rules.mk:469: warning: overriding commands for target `c'
../coreconf/rules.mk:465: warning: ignoring old commands for target `c'
../coreconf/rules.mk:964: *** multiple target patterns.  Stop.
make[2]: Leaving directory `/cygdrive/c/mozillaroot/mozilla/security/coreconf'
make[1]: *** [libs] Error 2
make[1]: Leaving directory `/cygdrive/c/mozillaroot/firefox/security/manager'
make: *** [all] Error 2

Reproducible: Always

Steps to Reproduce:
1. Install make 3.81 on Cygwin
2. Attempt to build
Actual Results:  
Many errors about "target `c'"

Expected Results:  
Successful build

It has been suggested that if this is not an easy fix, to put a check in configure.in and spit out an error if make 3.81 is used.
Attached patch Band-aid patch — — Splinter Review 
This is a band-aid to error out when make > 3.80 is used on Windows. I have never patched configure.in before so this is probably an ugly hack.
Attachment #230180 - Flags: review?(benjamin)
Try taking the "c:" out of all those strings shown above.

Recall that cygwin wants pure unix file system naming semantics,
meaning no drive letters.  That's why they created "/cygdrive".

I've been told that it is possible to configure cygwin to permit windows
file naming (with drive letters).  Maybe that's what you need to do.
So would the real issue here be that the new make wants the ':' character to be esacped as '\:'?
Let me set your expectations for this bug.  

First, I'm not sure it's an NSS bug.  
Might just be a configuration issue for some users. 

If removing the "c:" from the user's configuration strings cite above fixes it, 
then I'm inclined to say that that's the solution, to change the configuration
rather than the NSS files.  

Second, If a change to NSS is indicated, we'll be looking to a member of the
open source community to contribute that change as a patch to NSS.  To put it
another way, if you've got the problem, you're the best candidate to fix it!
(In reply to comment #4)
> Let me set your expectations for this bug.  
> 
> First, I'm not sure it's an NSS bug.  
> Might just be a configuration issue for some users. 
> 
> If removing the "c:" from the user's configuration strings cite above fixes it, 
> then I'm inclined to say that that's the solution, to change the configuration
> rather than the NSS files.  
> 
> Second, If a change to NSS is indicated, we'll be looking to a member of the
> open source community to contribute that change as a patch to NSS.  To put it
> another way, if you've got the problem, you're the best candidate to fix it!
> 

The configuration that does not work is the configuration that is used for all the official Mozilla builds.

As far as I know, the only reason all the WIN32 Tinderbox systems are not red is that they are not running the latest GNU make.
*** Bug 347236 has been marked as a duplicate of this bug. ***
(In reply to comment #5)
> The configuration that does not work is the configuration that is used for all
> the official Mozilla builds.

That said, it appears from more reading of cygwin threads, evidently when the new make was ported to cygwin support for DOS filenames was dropped.  The correct fix would be to use the cygpath command to convert the DOS path to a UNIX path if the OS is cygwin.  The question is, should that be done in the build for this component, or in the Mozilla build system before it gets to this point so that when it gets to building this component all the paths are in UNIX format already.  So, back to the NSS bug or Mozilla build system bug question.

On trunk trying to build in c-sdk/ldap/include I get: Makefile:89: *** target pattern contains no `%'. Stop.
Only thing I've changed recently is updating my cygwin install.
Yup, recent cygwin changes have the effect of breaking LOTS of existing 
makefiles, forcing lots of people to change their makefiles to be 
compatible with the new cygwin.  Can you imagine if c compilers did that?
Why cygwin thought this was a godo idea is beyond me.  
Best short term bet is to revert to previous version of cygwin make.
As far as I am concerned, we're not going to rewrite NSS's makefiles 
(or mozilla's makefiles) just because a new version of cygwin unilaterally, 
and without warning, decided to stop supporting drive name letters on windows.  

In my view, cygwin broke compatibility, and they should fix it.  

The patch attached above is not a patch to any NSS file.  
It does not change NSS, but rather changes some other product.

The NSS developers are in no position to review patches to other products' files.  So, either this bug will be resolved WONTFIX as an NSS bug, or it 
will be changed to be a bug on another product, whose developers can decide 
for themselves whether they will take that patch.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
Version: unspecified → 3.11
Per Nelson's request, I am moving this bug to Core: Build Config.

For what it's worth, I think we should take some patch for this on the Mozilla side (whether mine or something else). It's non-obvious that a .01 update to gmake would break the build, and it would be nice to point people in the right direction.
Status: RESOLVED → REOPENED
Component: Build → Build Config
Product: NSS → Core
Resolution: WONTFIX → ---
Version: 3.11 → Trunk
Assignee: nobody → nobody
Status: REOPENED → NEW
QA Contact: build → build-config
(In reply to comment #11)
> Per Nelson's request, I am moving this bug to Core: Build Config.
> 
> For what it's worth, I think we should take some patch for this on the Mozilla
> side (whether mine or something else). It's non-obvious that a .01 update to
> gmake would break the build, and it would be nice to point people in the right
> direction.
> 

The problem is that this does not really point people in the right direction.  If Cygwin does not change it's stance on this, then either the build needs to be changed to correctly use the cygpath command to convert all DOS style paths to UNIX style paths or a version of make that works needs to be included with the moztools for windows builds (if Cygwin licensing permits this).

The problem with just giving the error saying you need to find a back version of make will only work until 3.82 comes out.  This is becuase Cygwin only provides the current release and one back version.  Telling people they need to use version 3.80 or earlier, without providing any idea where to obtain that version, really does nothing to point people in the right direction.

Just my $0.02.
FYI, this should be resolved in the next version of GNU make, which will enable DOS pathname parsing by default when built for Cygwin.  GNU make in native DOS and Windows mode has always had support for DOS-style pathnames, but the Cygwin port of GNU make was using its own custom code for this.  The next release of GNU make will modify the configure script to turn on support for these paths by default when configured for a Cygwin environment.

For more information you can follow the various threads:

http://www.mail-archive.com/bug-make%40gnu.org/msg04154.html

The thread leading up to this patch also contains voluminous detail:

http://www.mail-archive.com/make-w32%40gnu.org/msg01121.html

If you want to try out this patch and let us know if it works or not that would be very helpful!


(In reply to comment #1)
> Created an attachment (id=230180) [edit]
> Band-aid patch
> 
> This is a band-aid to error out when make > 3.80 is used on Windows. I have
> never patched configure.in before so this is probably an ugly hack.
> 

If this is put in it needs to be modified because, evidently this will all be fixed in Gnu make 3.82 (see comment #13).  Also this gives the error on all windows builds even mingw, even though this works fine with the mingw version of make.
(In reply to comment #13)

> The thread leading up to this patch also contains voluminous detail:
> 
> http://www.mail-archive.com/make-w32%40gnu.org/msg01121.html
> 
> If you want to try out this patch and let us know if it works or not that would
> be very helpful!
> 

I got a copy of the cygwin 3.81-1 make, then applied this patch.  I then did a new pull of firefox trunk source, applied the patch from bug 325148 and tried to build.

It worked much better than the unpatched cygwin make, but there is still an issue.  I'm not sure where this happened, but somewhere a file path beginning with c:/ was evidently not treated as being an absolute path and it got treated as a relative path.

Here is a log snippet:

make[6]: Leaving directory `/cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/mangle'
Wed Aug 30 18:52:56 PDT 2006
cd c:/mozilla/trunk/nss ; sh /cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/sign.sh /cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/c:/mozilla/trunk/dist \
        /cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/c:/mozilla/trunk/nss WIN95 /cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/c:/mozilla/trunk/dist/lib \
        /cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/c:/mozilla/trunk/dist/lib/softokn3.dll
/cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/sign.sh: line 9: cd: /cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/c:/mozilla/trunk/dist: No such file or directory
/cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/sign.sh: line 14: cd: /cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/c:/mozilla/trunk/dist/lib: No such file or directory
/cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/c:/mozilla/trunk/nss/shlibsign -v -i /cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/c:/mozilla/trunk/dist/lib/softokn3.dll
/cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/sign.sh: line 22: /cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/c:/mozilla/trunk/nss/shlibsign: No such file or directory
make[5]: *** [c:/mozilla/trunk/dist/lib/softokn3.chk] Error 127
make[5]: Leaving directory `/cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign'
make[4]: *** [libs] Error 2
make[4]: Leaving directory `/cygdrive/c/mozilla/trunk/security/manager'
make[3]: *** [libs_tier_toolkit] Error 2
make[3]: Leaving directory `/cygdrive/c/mozilla/trunk'
make[2]: *** [tier_toolkit] Error 2
make[2]: Leaving directory `/cygdrive/c/mozilla/trunk'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/cygdrive/c/mozilla/trunk'
make: *** [build] Error 2

As you can see things like 'c:/mozilla/trunk/dist/lib/softokn3.dll' which should have been treated as an a bsolute path ended up with '/cygdrive/c/mozilla/trunk/security/nss/cmd/shlibsign/' being prepended.


An addition: Since the moztools ZIP contains GNU Make 3.79 under the name gmake.exe, and Make 3.79 seems to work, it might worth changing the build instruction so when you are building on Cygwin, you should use the "gmake" command, as opposed to just "make" (make.exe is Cygwin's Make 3.81, gmake.exe is Make 3.79 included with the moztools package).
(In reply to comment #16)

The gmake in moztools used to be the cause of problems on win32 and was not recommended. However, moztools was updated a while back (bug 242870) and this may no longer be the case.

Gmake of moztools is stil the old (buggy) one, however it would be possible to replace it with Cygwin's 3.80 make (renamed to gmake).
(In reply to comment #18)
> Gmake of moztools is stil the old (buggy) one, however it would be possible to
> replace it with Cygwin's 3.80 make (renamed to gmake).

And then update the official moztools package with the new, good gmake (v3.80).
Guys, let's not get into a situation where we're shipping cygwin binaries in moztools. Let's fix this bug at the code level somehow or other. Perhaps we can pass cygwin-style paths to the NSS make commands?
(In reply to comment #15)
> I got a copy of the cygwin 3.81-1 make, then applied this patch.  I then did a
> new pull of firefox trunk source, applied the patch from bug 325148 and tried
> to build.
> It worked much better than the unpatched cygwin make, but there is still an
> issue.  I'm not sure where this happened, but somewhere a file path beginning
> with c:/ was evidently not treated as being an absolute path and it got treated
> as a relative path.
> <log snipped>

This problem only occurs when you specify 400 (Win95) as the minimum OS version. Setting it to 500 (Windows 2000) fixes the problem. Also, it is unrelated to your make version, I had it with GNU make 3.80.

(In reply to comment #20)
> Guys, let's not get into a situation where we're shipping cygwin binaries in
> moztools. Let's fix this bug at the code level somehow or other. Perhaps we can
> pass cygwin-style paths to the NSS make commands?
> 

Exactly!

At least the following (perhaps there are more) need to be passed through the cygpath command to convert the paths to UNIX format.

SOURCE_MD_DIR=c:/mozilla/trunk/dist
DIST=c:/mozilla/trunk/dist
NSPR_INCLUDE_DIR=c:/mozilla/trunk/dist/include/nspr
NSPR_LIB_DIR=c:/mozilla/trunk/dist/lib
BUILD_TREE=c:/mozilla/trunk

I tried altering configure so it does not covert the MOZ_BUILD_ROOT to DOS format, but then ran into an issue because link does not understand the UNIX style path name.  (I figured there was some issue or else this kludge would not have been in configure in the first place).
(In reply to comment #21)
> (In reply to comment #15)
> > I got a copy of the cygwin 3.81-1 make, then applied this patch.  I then did a
> > new pull of firefox trunk source, applied the patch from bug 325148 and tried
> > to build.
> > It worked much better than the unpatched cygwin make, but there is still an
> > issue.  I'm not sure where this happened, but somewhere a file path beginning
> > with c:/ was evidently not treated as being an absolute path and it got treated
> > as a relative path.
> > <log snipped>
> 
> This problem only occurs when you specify 400 (Win95) as the minimum OS
> version. Setting it to 500 (Windows 2000) fixes the problem. Also, it is
> unrelated to your make version, I had it with GNU make 3.80.
> 

As far as I know 500 is the default for current trunk builds and the build works just fine with cygwin make version 3.80.
I am working on an additional patch to GNU make which I think will fix this.
This is back looking like another NSS bug.  The issue is NOT that we are passing windows path name.  there is a funciton called abspath in the Makefiles that is explicitly calling cygpath with the -w flag which converts paths to Windows format.

from security/coreconf/rules.mk

ifeq (,$(filter-out OS2 AIX,$(OS_TARGET)))
# OS/2 and AIX
NEED_ABSOLUTE_PATH := 1
PWD := $(shell pwd)

else
# Windows
ifeq (,$(filter-out _WIN%,$(NS_USE_GCC)_$(OS_TARGET)))
NEED_ABSOLUTE_PATH := 1
PWD := $(shell pwd)
ifeq (,$(findstring ;,$(PATH)))
ifndef USE_MSYS
PWD := $(subst \,/,$(shell cygpath -w $(PWD)))
endif
endif

else
# everything else
PWD := $(shell pwd)
endif
endif

abspath = $(if $(findstring :,$(1)),$(1),$(if $(filter /%,$(1)),$(1),$(PWD)/$(1)
))

I figured out what is happening here.  I expect to have an additional short patch for gnu make later today.
SUCCESS!

I managed to successfully build the WIN32 Trunk Firefox using make 3.81!

I was confused in comment #25.  The code that is not working is NOT calling the abspath defined in rules.mk.  It is calling the GNU make built-in abspath function.

It turns out that the GNU make abspath function has no code in it to detect if the input path is, in fact, an absolute path in DOS format.  Therefore it ends up garbling the path trying to convert it to an absolute path.

So, in addition to the patch linked to in comment #13, the following is also required:

--- function.c.0~       2006-09-02 21:23:23.218750000 -0400
+++ function.c  2006-09-02 18:14:47.234375000 -0400
@@ -1882,16 +1882,25 @@
 abspath (const char *name, char *apath)
 {
   char *dest;
   const char *start, *end, *apath_limit;

   if (name[0] == '\0' || apath == NULL)
     return NULL;

+#ifdef HAVE_DOS_PATHS
+
+/* If a DOS style absolute path is detected, just copy it and return. */
+  if (name[0] != '/' && name[1] == ':') {
+    strncpy (apath, name, GET_PATH_MAX);
+    return apath;
+  }
+#endif
+
   apath_limit = apath + GET_PATH_MAX;

   if (name[0] != '/')
     {
       /* It is unlikely we would make it until here but just to make sure. */
       if (!starting_directory)
        return NULL;


Temporary solution to this error:

../coreconf/rules.mk:365: target `c' doesn't match the target pattern
../coreconf/rules.mk:406: target `c' doesn't match the target pattern
../coreconf/rules.mk:407: warning: overriding commands for target `c'
../coreconf/rules.mk:366: warning: ignoring old commands for target `c'
../coreconf/rules.mk:437: target `c' doesn't match the target pattern
../coreconf/rules.mk:438: warning: overriding commands for target `c'
../coreconf/rules.mk:407: warning: ignoring old commands for target `c'
../coreconf/rules.mk:445: target `c' doesn't match the target pattern
../coreconf/rules.mk:446: warning: overriding commands for target `c
../coreconf/rules.mk:438: warning: ignoring old commands for target `c'
../coreconf/rules.mk:449: target `c' doesn't match the target pattern
../coreconf/rules.mk:450: warning: overriding commands for target `c'
../coreconf/rules.mk:446: warning: ignoring old commands for target `c'
../coreconf/rules.mk:464: target `c' doesn't match the target pattern
../coreconf/rules.mk:465: warning: overriding commands for target `c'
../coreconf/rules.mk:450: warning: ignoring old commands for target `c'
../coreconf/rules.mk:468: target `c' doesn't match the target pattern
../coreconf/rules.mk:469: warning: overriding commands for target `c'
../coreconf/rules.mk:465: warning: ignoring old commands for target `c'
../coreconf/rules.mk:966: *** multiple target patterns.  Stop.

** make 3.80 is no longer available in the Cygwin setup installer, so you'll have to find it yourself. You can google for make-3.80-1.tar.bz2 and it's also available at [http://cygwin.paracoda.com/release/make/make-3.80-1.tar.bz2].

**After installation, you could just grab the Make executable file (make.exe) from <b>/usr/bin/</b> and drop it in <b>Cywgin/bin</b> (this will overwrite the existing Make executable).

This patch allows the build to complete with MSYS make 3.81, while still working with cygwin make 3.80. It does not fix cygwin make 3.81.
Assignee: nobody → benjamin
Status: NEW → ASSIGNED
Attachment #244858 - Flags: review?(wtchang)
Comment on attachment 244858 [details] [diff] [review]
NSS and mozilla-driver patch to build with MSYS make 3.81

Ben, thanks for the patch.

I can summarize the changes to security/coreconf as follows.

1. The arguments to the -OUT, -DEF, -Fe, -Fo, ... options of Windows
build tools must be passed to the new winpath function.

These winpath function calls make our makefile less maintainable.  I
hope there is a better solution, e.g., using a script similar to
cygwin-wrapper.

2. Don't use the -PDB:NONE linker option.

I presume this option is no longer supported by the latest Visual
C++ and generates a warning.  If so, I remember I have a patch
for this problem.

3. Remove the subst function calls in $(subst /,\\,$(OBJS)).

It seems that we added the subst calls so that pathnames that
begin with / such as /temp/nss-build/nss/dbm/db.obj won't be
considered as a command-line option by Windows development tools.
The problem with pathnames such as /temp/nss-build/nss/dbm/db.obj
can be avoided by using the drive letter, e.g.,
C:/temp/nss-build/nss/dbm/db.obj.  So it seems that we can
take this change.  But we will need to do more testing, in
particular with the MKS Toolkit that many NSS developers use.
> 1. The arguments to the -OUT, -DEF, -Fe, -Fo, ... options of Windows
> build tools must be passed to the new winpath function.
> 
> These winpath function calls make our makefile less maintainable.  I
> hope there is a better solution, e.g., using a script similar to
> cygwin-wrapper.

I figured that you didn't want to add a wrapper script. If a wrapper script is acceptable I can probably fix cygwin as well as MSYS.

> 2. Don't use the -PDB:NONE linker option.
> 
> I presume this option is no longer supported by the latest Visual
> C++ and generates a warning.  If so, I remember I have a patch
> for this problem.

It in fact tries to create a file called NONE.pdb.

This patch fixes usage of the $(abspath) function in GNU make. gmake 3.81 added abspath as a "builtin" function, which overrides user-set functions. This works fine on linux, but on Windows it ends up returning a unix-style path instead of a windows-style path.

This patch allows MSYS make 3.81 (prerelease) to build Mozilla properly. Hopefully the same thing will work for cygwin make whenever they get around to doing another release.

I'm hoping we can backport this to all the active NSS branches.
Attachment #246985 - Flags: review?(wtchang)
For more information about the builtin abspath, see http://lists.gnu.org/archive/html/make-w32/2006-09/msg00042.html

and also, for a lengthy and bizarre discussion about whether abspath ought to handle windows-style paths, see http://lists.gnu.org/archive/html/make-w32/2006-05/msg00038.html
I still hit the problem shown in comment #0 with this patch (both patches actually).  Is there a specific patch we are waiting for the cygwin guys to apply or should we start making NSS cygwin-wrapper friendly?

Forgot to mention that I'm using cygwin make 3.81.  (I had a completely different set of problems at configure time with msys make.)
cls, the version of MSYS make I'm testing with is a private prerelease version that should be out as a snapshot tomorrow or Friday. The current snapshot was built without HAVE_DOS_PATHS. I don't know what's up with cygwin (and have stopped caring, for the most part).
(In reply to comment #36)
> cls, the version of MSYS make I'm testing with is a private prerelease version
> that should be out as a snapshot tomorrow or Friday. The current snapshot was
> built without HAVE_DOS_PATHS. I don't know what's up with cygwin (and have
> stopped caring, for the most part).
> 

cygwin is basically running the stock GNU make.  3.81 ends up NOT setting HAVE_DOS_PATHS for cygwin.  3.82 will set HAVE_DOS_PATHS for cygwin so whenever that is released this patch will make cygwin work correctly as well.  I have been running with the patches that are so far intended to be included with GNU make 3.82 and it builds with that (what I am running also includes a patch to abspath to make it work with DOS paths (this patch makes abspath always return a DOS path if HAVE_DOS_PATHS is defined.  I understand a further patch is being worked to somehow permit it to return either DOS or POSIX paths in the cygwin case.  I suspect that might make the NSS bild no longer work, but the patch you are proposing would make that no longer matter.

If there is interest I suppose I could post the patched executable to this bug.
Benjamin, your patch is fine.  I use core_abspath instead of
nss_abspath because security/coreconf is also used by non-NSS
projects.  I also wrap a long line in security/nss/cmd/shlibsign/Makefile.

Christophe, this patch simply changes abspath to core_abspath
globally because gmake 3.81 has a built-in function named abspath.
Is it okay to check in this patch on the NSS_3_11_BRANCH for Mozilla?
Attachment #246985 - Attachment is obsolete: true
Attachment #247751 - Flags: superreview?(christophe.ravel.bugs)
Attachment #247751 - Flags: review+
Attachment #246985 - Flags: review?(wtchang)
Attachment #247751 - Flags: superreview?(christophe.ravel.bugs) → superreview+
(In reply to comment #38)
> Created an attachment (id=247751) [edit]
> Fix abspath in gmake 3.81, rev. 2 (by Benjamin Smedberg)
> 
It looks to me that with this patch, and the patch linked to in comment #13 (which is scheduled to be included in make 3.82) applied to make 3.81, the build would then work under cygwin.  So, this should be sufficient to fix even the cygwin make case once make 3.82 is released.
Comment on attachment 247751 [details] [diff] [review]
Fix abspath in gmake 3.81, rev. 2 (by Benjamin Smedberg)

I checked in the NSS/coreconf abspath patch on the NSS trunk
(NSS 3.12) and NSS_3_11_BRANCH (NSS 3.11.5).
Flags: wanted1.8.1.x?
Flags: wanted1.8.0.x?
Attachment #244858 - Flags: review?(wtchang)
I'm going to mark this FIXED because it works with MSYS now, and we're dropping cygwin support.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Actually this fix is sufficient for cygwin as well.  It builds fine with cygwin and gnu make pulled form the current cvs tree (which is now version 3.81.90.  So, there is no reason to believe this will not be fixed for cygwin by the release of GNU make 3.82.
Attachment #230180 - Flags: review?(benjamin)
Flags: wanted1.8.1.x?
Flags: wanted1.8.0.x?
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.