Closed
Bug 207521
Opened 21 years ago
Closed 17 years ago
cannot build tree under cygwin root directory (error D2003)
Categories
(Firefox Build System :: General, enhancement)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: will.sargent, Unassigned)
References
Details
Attachments
(1 file, 3 obsolete files)
6.19 KB,
patch
|
Details | Diff | Splinter Review |
After I type 'make -f client.mk build_all', everything goes through a configure stage, and then tries to build with the following: make[4]: Entering directory `/home/wsargent/mozilla/nsprpub/config' sh /home/wsargent/mozilla/nsprpub/build/cygwin-wrapper cl -Fonow.obj -c -W3 -nologo -GF -Gy -MDd -Od -Z7 -UNDEBUG -DDEBUG_wsargent -UWINNT -DMOZILLA_CLIENT=1 -DDEBUG=1 -DXP_PC=1 -DWIN32=1 -D_DEBUG=1 -DWIN95=1 -D_PR_GLOBAL_THREADS_ONLY=1 -D_X86_=1 -DFORCE_PR_LOG /home/wsargent/mozilla/nsprpub/config/now.c Command line warning D4002 : ignoring unknown option '/home/wsargent/mozilla/nsprpub/config/now.c' Command line error D2003 : missing source filename make[4]: *** [now.obj] Error 2 make[4]: Leaving directory `/home/wsargent/mozilla/nsprpub/config' make[3]: *** [export] Error 2 make[3]: Leaving directory `/home/wsargent/mozilla/nsprpub' make[2]: *** [nspr] Error 2 make[2]: Leaving directory `/home/wsargent/mozilla' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/wsargent/mozilla' make: *** [build] Error 2 I'm pretty sure that's not supposed to happen. Update: well, apparently cl is stupid. Cygwin is smart enough to know that if HOME=d:\home\wsargent and mount -s /home is set, then the appropriate path is /home/wsargent. But cl expects d:/home/wsargent, and cygwin-wrapper will only strip the /cygdrive/ header off of a non-mounted /home. How sucky. I will try to write a patch using 'cygpath -m $DIR'. This might be integrated with bug #206643.
See http://bugzilla.mozilla.org/show_bug.cgi?id=158920#c0 for why cygpath was shunned to begin with. There are other comments in that bug that are relevant as well. For my patch in bug #206643, I avoided using cygpath for the same reasons. I think cygwin-wrapper could be made smarter, but I don't want it to rely on cygpath for every path translation because the extra overhead for starting a new process is so high (which matters to me on my old, slow machine).
Comment 2•21 years ago
|
||
This particular problem was referenced at bug http://bugzilla.mozilla.org/show_bug.cgi?id=158920#c11 . Right now, building under /home, which is actually c:/cygwin/home, is not supported.
Severity: minor → enhancement
Summary: cygwin-wrapper does not work for mounted /home → cannot build tree under cygwin root directory
Comment 3•21 years ago
|
||
I see you have a "problem" "nsinstall or another native win32 program complains about a file not being found" listed under "Common Problems and Hints" in the build instructions. Unfortunately, I didn't see that at all, although I hit this bug and was specifically looking in the build instructions to see, if I missed something that was added recently. Even reading the text now, it is less than clear - my drive partition *is* mounted under /cygdrive/, but *also* mounted under e.g. /mozsrc/, and I used the latter to access it, and the build broke in non-obivous ways. So, how about something like this text instead (please correct, if incorrect): "file not found compiler error e.g.: [list exact compiler output, incl. keywords D2003 and D4002, for NSPR's now.c] or nsinstall or another native win32 program doesn't find a file. First check your... The build system expects that the all relevant drive partitions (tools, source, objdir) are mounted using /cygdrive as the drive prefix and referenced this way. So, if (in the example) c: or e: does not use /cygdrive as the drive prefix, then you cannot build Mozilla using those drives. You will need to man... Also, you cannot use additional mount points like /mozsrc/ or /home/ to access relevant files." Could you please also create a section "Restrictions" where you document such arbitary restrictions of the build system, and link that section under the main build steps where you list the requirements? Listing that under "Common Problems and Hints" is non-obvious to me, because I would expect that section to contain help for me when *I* did something wrong, not when the *build system* decided not to support my (valid) system. Ideally, the build system should catch stuff like this in configure. Took me considerable time to sort out. BTW: It works just fine with older Mozillas (1.0 in my case).
Summary: cannot build tree under cygwin root directory → cannot build tree under cygwin root directory (error D2003)
Mass reassign of Build/Config bugs to Leaf.
Assignee: mozbugs-build → leaf
Comment 5•20 years ago
|
||
Hey, I think this goes here: I was trying to build mozilla using vc7.1, and here is what i got: cl -Fohost_cppsetup.o -c -TC -nologo -DXP_WIN32 -DXP_WIN -DWIN32 -D_WIN32 -DNO_X 11 -DINCLUDEDIR=\"/usr/include\" -DOBJSUFFIX=\".obj\" -I../../dist/include/mkd epend -I../../dist/include -I../../dist/include/nspr -I../../dist/include/ns pr /cygdrive/g/mozilla/config/mkdepend/cppsetup.c cl : Command line warning D4002 : ignoring unknown option '/cygdrive/g/mozilla/c onfig/mkdepend/cppsetup.c' cl : Command line error D2003 : missing source filename make[3]: *** [host_cppsetup.o] Error 2 make[3]: Leaving directory `/cygdrive/g/mozilla/config/mkdepend' make[2]: *** [export] Error 2 make[2]: Leaving directory `/cygdrive/g/mozilla/config' make[1]: *** [default] Error 2 make[1]: Leaving directory `/cygdrive/g/mozilla' make: *** [build] Error 2 i have no /home or anything like that. My mozilla source is in g:\mozilla, but it is referenced to as /cygdrive/g/mozilla . cl thinks that / is the indication of an option and ignores it, while in reality it specifies a source file. Any ideas if this is a bug or i am doing something wrong?
Somehow, you're building on win32 without CYGWIN_WRAPPER set. cygwin-wrapper is what translates the cygwin paths into dos paths for the native win32 progs (like cl.exe). A full build log would be helpful in tracking down the problem.
Please help: These bug occurs to me as well. But only when trying to build with c1. Building with MinGW works. I extracted the tarball and updated it with cvs -z3 checkout -PA mozilla/mail/config make -f mozilla/client.mk checkout MOZ_CO_FLAGS=-PA The I tried to build with "make -f client.mk build" My mozconfig is: [Quote] . $topsrcdir/mail/config/mozconfig #ac_add_options --enable-default-toolkit=gtk2 #ac_add_options --enable-xft # Note: remove enable-optmize and disable debug if you want a debug build #ac_add_options --enable-optimize=-O2 #ac_add_options --disable-optimize #ac_add_options --enable-debug #ac_add_options --enable-image-decoders=png,gif,jpeg,bmp export BUILD_OFFICIAL=1 export MOZILLA_OFFICIAL=1 mk_add_options BUILD_OFFICIAL=1 mk_add_options MOZILLA_OFFICIAL=1 [/Quote] my Mozset.bat: [Quote] set MOZ_TOOLS=C:\moztools set HOME=C:\home set CVSROOT=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot set PATH=D:\Programme\Microsoft Visual Studio\VC98\Bin;D:\WINDOWS\system32;D:\WINDOWS;D:\WINDOWS\System32\Wbem;c:\moztools\bin;c:\cygwin\bin;c:\masm32\bin;%path% set LIB=D:\Programme\Microsoft Visual Studio\VC98\Lib;D:\Programme\Microsoft Visual Studio\VC98\MFC\Lib;c:\masm32\lib;%lib% set INCLUDE=D:\Programme\Microsoft Visual Studio\VC98\Include;D:\Programme\Microsoft Visual Studio\VC98\MFC\Include;D:\Programme\Microsoft Visual Studio\VC98\ATL\Include;c:\masm32\include;%include% cd C:\cygwin\bin\ mount -s C:\ /cygdrive/c mount -s D:\ /cygdrive/d mount cd\ [/quote] As you see, I made sure that both drives were mounted in binmode. But why doesn't the wrapper work and reports unix style commands to cl? Any help would be highly appreciated. I surfed the web and the esepecially the building FAQs without success for weeks now.
Comment on attachment 148154 [details] Build log of my Thunderbird 0.6 build try This looks like a completely separate problem. You're calling cygwin-wrapper twice. That appears to be caused by http://lxr.mozilla.org/seamonkey/source/configure.in#1144
Comment 10•20 years ago
|
||
hmm. Why is that for me. The error message is the same as for Laimonas Simutis. What am I supposed to prevent/circumvent the problem (and why is only a problem for me?). For now I tried to edit my configure.in (in the \mozilla\ directory) and removed line 1144 as you suggested, but the error message remained. I attached a new buildlog (this time a firefox source pulled from cvs a few days ago with that line removed in configure.in). Please help (I wanted to switch from GNU C to MSVC to circumvent the Java plugin issue with GNU builds).
Comment 11•20 years ago
|
||
Not sure why either of you are hitting that error message. I thought Bernd's problem was because we're calling cygwin-wrapper twice but the msvc win32 tinderboxes are doing it as well and it works fine there. And both problems are still separate issues from the original problem reported in this bug. Try running the wrapper by hand and using 'sh -x' and see what it spits out.
Comment 12•20 years ago
|
||
Thanks for looking into it. I put the onscreen output into a .txt file (the error remains - of course :( ).
Comment 13•20 years ago
|
||
Comment on attachment 148278 [details] Log of the manual SH Command >+ mount -p >Signal 127 >+ mountpoint= >Mount/Umount tools by Matt Wu <mattwu@163.com>. > http://sysinternals.yeah.net. >+ mountpoint=/Umount There's your problem. The script expects that mount is cygwin's mount program. You have another mount program in your path before cygwin's so the script is getting all of the wrong results.
Comment 14•20 years ago
|
||
Thanks. That did it!!! I used to install Linux on another HD (Ext2) partition. I had a Windows Ext2 driver installed to be able to access the Linux partition from my Windows systems. And guess: A mount.exe did the job of mounting the linux drive and it was placed in my \Windows\system32\ directory. I wouldn't have figured out alone, that this conflicted with the cygwin mount.exe. Thanks a lot, you rule!
Updated•20 years ago
|
Assignee: leaf → cmp
Updated•20 years ago
|
Product: Browser → Seamonkey
Rather then the currect 'generic' algorithm that tries to do general fixup of cygwin paths, wouldn't a better approach be something that just did search'n'replace of the path that is currently being built. I.e. if configure figures out that mozilla is currently located in /cygdrive/d/moz/trees/trunk/mozilla call cygpath with that path and get D:/moz/trees/trunk/mozilla Once we know that all that is needed is to replace "/cygdrive/d" with "D:". And if we find that the current buildpath is /home/Jonas/moz/source/mozilla and cygpath gives H:/moz/source/mozilla then we just replace "/home/Jonas" with "H:/". I.e. during configure, figure out as short replacement string as possible, set two variables for what to replace, and we're done. The only problem with this would be if someone has the objdir at a different drive then the sourcedir, but that doesn't seem very likly.
Comment 16•19 years ago
|
||
> The only problem with this would be if someone has the objdir at a different
> drive then the sourcedir, but that doesn't seem very likly.
There are good reasons for that, e.g. to keep a data partition (source) and one
where lots oc disk activity (build) is. I don't do that currently, but I
wouldn't prevent it.
Actually, we could handle even that case with a system like this. All we'd need to do is to set up two search'n'replace variable pairs. One for the source tree and optionally another one for the bintree. If they happen to exist in the same place in the tree we'd just leave the second pair empty.
Comment 18•18 years ago
|
||
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build
Comment 19•18 years ago
|
||
"Don't do that."
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
Comment 20•18 years ago
|
||
*** Bug 343354 has been marked as a duplicate of this bug. ***
Comment 21•18 years ago
|
||
I'm not sure if I care enough to reopen the bug but here's a fix. Alex Vincent's patch from bug 343354 provided the insight. With this patch, I can build from my cygwin home dir...using gcc at least. I haven't measured the differences. When building under the cygwin mount, TMP or TMPDIR must be set or else windres complains about not being able to create a tmp file in \/random.irc .
Attachment #148154 -
Attachment is obsolete: true
Attachment #148263 -
Attachment is obsolete: true
Attachment #148278 -
Attachment is obsolete: true
Comment 22•18 years ago
|
||
reopening for reconsideration
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 23•17 years ago
|
||
re-WONTFIXing, per comment 19.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 17 years ago
Resolution: --- → WONTFIX
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•