cygwin environment build failure at 'ecl-exp.h'

VERIFIED WORKSFORME

Status

NSS
Build
VERIFIED WORKSFORME
14 years ago
13 years ago

People

(Reporter: Waldo, Assigned: Wan-Teh Chang)

Tracking

unspecified
3.10
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(URL)

I'm following the instructions at <http://gemal.dk/mozilla/build.html> (with
minor changes for different directories and drives).  I am building Firefox and
not Mozilla/Thunderbird/NSS.  I assume this is the proper product/component for
the bug, but I might be wrong.  Feel free to move if deemed necessary.

When I build using the above system (at Windows command prompt with properly set
PATH variables through a properly created mozset.bat), the build process goes
along merrily for quite a while.  At some point during the build (it takes long
enough on my system that I've only built when I'm away from the computer for an
extended period of time) I get the following bit of information (more context
available at URL if needed):


make[4]: Leaving directory `/cygdrive/m/mozilla/mozilla/security/coreconf'
cd ../../dist/lib; cp -f libdbm32.a libdbm.a
/usr/bin/make -C /cygdrive/m/mozilla/mozilla/security/nss/lib MAKE="/usr/bin/mak
e -j1" -j1 MOZILLA_INCLUDES="-Im:/mozilla/mozilla/dist/include/nspr -Im:/mozilla
/mozilla/dist/include/dbm" SOURCE_MD_DIR=m:/mozilla/mozilla/dist DIST=m:/mozilla
/mozilla/dist MOZILLA_CLIENT=1 NO_MDUPDATE=1 BUILD_TREE=m:/mozilla/mozilla BUILD
_OPT=1 NS_USE_GCC=1 NS_USE_NATIVE= OS_TARGET=WIN95
make[4]: Entering directory `/cygdrive/m/mozilla/mozilla/security/nss/lib'
cd util; /usr/bin/make -j1 export
make[5]: Entering directory `/cygdrive/m/mozilla/mozilla/security/nss/lib/util'
Creating m:/mozilla/mozilla/dist/public/nss
nsinstall -m 444 base64.h ciferfam.h nssb64.h nssb64t.h nsslocks.h nssilock.h ns
silckt.h nssrwlk.h nssrwlkt.h portreg.h secasn1.h secasn1t.h seccomon.h secder.h
 secdert.h secdig.h secdigt.h secitem.h secoid.h secoidt.h secport.h secerr.h wa
tcomfx.h m:/mozilla/mozilla/dist/public/nss
Creating m:/mozilla/mozilla/dist/private/nss
nsinstall -m 444 pqgutil.h m:/mozilla/mozilla/dist/private/nss
make[5]: Leaving directory `/cygdrive/m/mozilla/mozilla/security/nss/lib/util'
cd freebl; /usr/bin/make -j1 export
make[5]: Entering directory `/cygdrive/m/mozilla/mozilla/security/nss/lib/freebl
'
make[5]: *** No rule to make target `ecl-exp.h', needed by `export'.  Stop.
make[5]: Leaving directory `/cygdrive/m/mozilla/mozilla/security/nss/lib/freebl'

make[4]: *** [export] Error 2
make[4]: Leaving directory `/cygdrive/m/mozilla/mozilla/security/nss/lib'
make[3]: *** [libs] Error 2
make[3]: Leaving directory `/cygdrive/m/mozilla/mozilla/security/manager'
make[2]: *** [tier_40] Error 2
make[2]: Leaving directory `/cygdrive/m/mozilla/mozilla'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/cygdrive/m/mozilla/mozilla'
make: *** [build] Error 2


My .mozconfig is relatively mundane:


. $topsrcdir/browser/config/mozconfig
CC=gcc
CXX=g++
CPP=cpp
AS=as
LD=ld
export BUILD_OFFICIAL=1
export MOZILLA_OFFICIAL=1
mk_add_options BUILD_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1

ac_add_options --disable-debug
ac_add_options --enable-optimize
ac_add_options --enable-official-branding
# these apparently don't work yet, disabling
ac_add_options --disable-accessibility
ac_add_options --disable-activex


Once again, I don't know if this is an NSS thing, a Firefox build thing, or a
cygwin/MinGW thing.  I filed it in NSS because that's where the breakage occurs.
(Assignee)

Comment 1

14 years ago
Hi. I have no idea what's wrong.  I don't build NSS
with MinGW.  Let me know if you find out anything.

Comment 2

14 years ago
I've seen several people mention this in the mozillazine forums but I've never
been able to reproduce it.  Can you verify that
mozilla/security/nss/lib/freebl/ecl/ecl-exp.h exists?
(In reply to comment #2)
> Can you verify that mozilla/security/nss/lib/freebl/ecl/ecl-exp.h exists?

After the build, yes, it did exist.  It also is part of the CVS tree as well, as
the icon has the TortoiseCVS "green" (=up-to-date) overlay.  See also the file
in LXR:

http://lxr.mozilla.org/mozilla/source/security/nss/lib/freebl/ecl/ecl-exp.h

I'm attempting to reproduce the build error now with a freshly-pulled, clean
tree to be absolutely certain, but I'm having problems doing so, probably due to
the massive changes since I last updated my tree.  I've just started a build,
and hopefully it'll complete by morning (old machine, ~3.5 hours to build). 
I'll post my results then (results hopefully untainted by extraneous
postbranch-induced instability errors).

Also, my .mozconfig (which I probably should have posted earlier):

. $topsrcdir/browser/config/mozconfig
CC=gcc
CXX=g++
CPP=cpp
AS=as
LD=ld
export BUILD_OFFICIAL=1
export MOZILLA_OFFICIAL=1
mk_add_options BUILD_OFFICIAL=1
mk_add_options MOZILLA_OFFICIAL=1
ac_add_options --disable-debug
ac_add_options --enable-optimize
# these apparently don't work yet, disabling
ac_add_options --disable-accessibility
ac_add_options --disable-activex
My build failed with an error unrelated to this one.  I'm trying another
pull/build as it appears I might have hit during a burning tree, but I'm not
sure about it.

And yes, I did know I'd already posted a .mozconfig...I figured a different look
at it might be useful.  Or at least that's what I like to tell myself.  ;-)  I
can be pretty dumb sometimes.
Interesting...I just reproduced this bug while attempting a compile using the
new free MS VC++ toolkit (which was chugging along fine until it hit this).  The
file mentioned in comment 2 was present exactly where expected.  I was using the
cygwin environment for the build (naturally - nothing else is supported), but
aside from that I don't believe anything else remained common.  It was a "new"
installation of cygwin as well; the install was to a previously-used location,
but it was to a partition that had been newly created.  The source tree was a
completely new pull as well for the same reason.

I'm confused here.  Could the problem be with one of the build programs?  I'm
using (among others):

make       - 3.80
cl         - 13.10.3052
ActivePerl - 5.6.1 build 638
grep       - 2.5
unzip      - 5.50
zip        - 2.3
gawk       - 3.1.3
sed        - 4.0.9

I was running the tools from a Windows command prompt (cygwin was in PATH).  All
the tools are standard tools, latest version from cygwin except for cl (part of
VC++ toolkit) and ActivePerl (ActiveState).  I don't have autoconf installed.

If there's any other information I can provide about my build environment, I'm
more than willing to provide it.
Summary: MinGW/cygwin build failure at 'ecl-exp.h' → cygwin environment build failure at 'ecl-exp.h'
(Assignee)

Comment 6

13 years ago
The key to this build step is this vpath statement

    vpath %.h mpi ecl

in mozilla/security/nss/lib/freebl/Makefile.  It is
not working for those who experienced this bug.  I
don't know why.

Try breaking it into two statements:

    vpath %.h mpi
    vpath %.h ecl
(In reply to comment #6)
> Try breaking it into two statements:
> 
>     vpath %.h mpi
>     vpath %.h ecl

I tested this, but I'm still getting the same error.  Might any of the other
lines nearby need to be split up?
(Assignee)

Comment 8

13 years ago
The other vpath lines are for other types of files.
They do not affect .h files.

Comment 9

13 years ago
As a guess....

Does the patch for Bug #267839 have anything to do with this problem?
(Assignee)

Comment 10

13 years ago
No.  Those makefile rules are not related to this bug.

Comment 11

13 years ago
An upgrade of cygwin's coreutils (released today) fixed this problem for me.
(In reply to comment #11)
> An upgrade of cygwin's coreutils (released today) fixed this problem for me.

I can't reproduce the problem any more, so I'm willing to mark it WORKSFORME. 
Upgrading coreutils wasn't what did it, tho, because I compiled Firefox over a
month ago (clearly before the coreutils release) without hitting this snag.  I
was using a different system, tho (still WinXP on both), so I have no idea what
the difference was.  Anyway, if no one else can reproduce this bug within the
next several weeks or so, I'll mark it WFM.
(Assignee)

Comment 13

13 years ago
Marked the bug WORKSFORME.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → 3.10

Comment 14

13 years ago
V'ing
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.