207521 - cannot build tree under cygwin root directory (error D2003)

Status: RESOLVED WONTFIX

(Firefox Build System :: General, enhancement)

Description

[Will Sargent]

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.

Comment 1

[paxunix]

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

[hacker formerly known as [e-mail]]

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.

Comment 3

[Ben Bucksch (:BenB)]

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).

Comment 4

[(default assignee for unassigned bugs. does not receive bugmail)]

Mass reassign of Build/Config bugs to Leaf.

Comment 5

[Laimonas Simutis]

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?

Comment 6

[cls]

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.

Comment 7

[amano]

Attachment: Build log of my Thunderbird 0.6 build try

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:[e-mail]:/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 8

[amano]

Adding Chris Seawood to the cc list, since he requested a build log.

Comment 9

[cls]

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

[amano]

Attachment: Firefox (pulled from CVS) buildlog.

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

[cls]

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

[amano]

Attachment: Log of the manual SH Command

Thanks for looking into it. I put the onscreen output into a .txt file (the
error remains - of course :( ).

Comment 13

[cls]

Comment on attachment 148278 [details]
Log of the manual SH Command


>+ mount -p
>Signal 127
>+ mountpoint=
>Mount/Umount tools by Matt Wu <[e-mail]>.
>                      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

[amano]

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!

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

[Ben Bucksch (:BenB)]

> 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.

Comment 17

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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

[Chase Phillips]

Mass reassign of open bugs for [e-mail] to [e-mail].

Comment 19

[Benjamin Smedberg]

"Don't do that."

Comment 20

[cls]

*** Bug 343354 has been marked as a duplicate of this bug. ***

Comment 21

[cls]

Attachment: v1.0

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 .

Comment 22

[Alex Vincent [:WeirdAl]]

reopening for reconsideration

Comment 23

[J. Paul Reed [:preed]]

re-WONTFIXing, per comment 19.