Closed
Bug 239643
Opened 20 years ago
Closed 19 years ago
cygwin environment build failure at 'ecl-exp.h'
Categories
(NSS :: Build, defect)
Tracking
(Not tracked)
VERIFIED
WORKSFORME
3.10
People
(Reporter: Waldo, Assigned: wtc)
References
()
Details
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•20 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.
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?
Reporter | ||
Comment 3•20 years ago
|
||
(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
Reporter | ||
Comment 4•20 years ago
|
||
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.
Reporter | ||
Comment 5•20 years ago
|
||
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•20 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
Reporter | ||
Comment 7•20 years ago
|
||
(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•20 years ago
|
||
The other vpath lines are for other types of files. They do not affect .h files.
Comment 9•20 years ago
|
||
As a guess.... Does the patch for Bug #267839 have anything to do with this problem?
Assignee | ||
Comment 10•20 years ago
|
||
No. Those makefile rules are not related to this bug.
Comment 11•20 years ago
|
||
An upgrade of cygwin's coreutils (released today) fixed this problem for me.
Reporter | ||
Comment 12•20 years ago
|
||
(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•19 years ago
|
||
Marked the bug WORKSFORME.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
Target Milestone: --- → 3.10
You need to log in
before you can comment on or make changes to this bug.
Description
•