Closed
Bug 158920
Opened 22 years ago
Closed 21 years ago
build fails if cygwin mount prefix is not /cygdrive
Categories
(SeaMonkey :: Build Config, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.4beta
People
(Reporter: netscape, Assigned: netscape)
References
Details
Attachments
(4 files, 2 obsolete files)
5.90 KB,
patch
|
bryner
:
review+
|
Details | Diff | Splinter Review |
1.31 KB,
patch
|
Details | Diff | Splinter Review | |
2.42 KB,
patch
|
Details | Diff | Splinter Review | |
1.86 KB,
patch
|
Details | Diff | Splinter Review |
I thought that we had fixed this at one point but it seems to have been resurrected with the fix of bug 141834. Cygwin uses /cygdrive/X/foo/bar to denote the path to files on drive X, if X is a cyg-mounted drive. If the drive is unmounted, cygwin uses /X/foo/bar/. Both conventions already screw up non-cygwin programs but this is doubly annoying. While both are easy enough to check for via sed, the first has far less of a chance of hitting a false positive. Using `cygpath -w` to translate either type of path into a regular dos path seems to work. However, we do not use cygpath in the cygwin-wrapper script since cygpath only works on a single argument, not a list of arguments. Instead we assume that /cygdrive/ is used which breaks when the drive isn't cyg-mounted. Potential solutions: 1) Start using cygpath in the wrapper script. This is nasty as it means invoking a separate process for *each* argument passed through the script. 2) Skip the wrapper script altogether. In the main build, we use the script as little as possible. It's still used for a handful of things though, namely running rc, perl & nsinstall. nsinstall is the main sore spot as it can accept a variable number of filename args which each would need to be checked. NSPR & LDAP use the wrapper pretty much everywhere. 3) Hack cygpath to accept multiple args so that we could use cygpath in the wrapper in lieu of sed. This means yet another entry from wintools or hoping that cygnus will accept the changes and bump the minimum rev of the cygwin tools required.
Comment 1•22 years ago
|
||
I vote for solution 3.
Assignee | ||
Comment 2•22 years ago
|
||
I forgot to mention the obvious but potentially unfriendly option of requiring that the drive be cygwin mounted before we can build. I don't know of any immediate side-effects of mounting but people aren't going to like the extra step.
So, um, I'm not sure how to naturally reproduce this bug. When I converted one of my linux partitions into a ntfs partition, it showed up in my mount table as /cygdrive/e/ automatically. It also has a noumount attribute and I can't seem to umount it. This is on w2k.
Comment 4•22 years ago
|
||
I think the cygwin installer records the mount information in the Windows registry. On my installation this is at: HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 You should be able to use regedit.exe to edit the registry entries to get rid of the mount points.
Assignee | ||
Comment 5•22 years ago
|
||
It must be keeping these particular drive mount points elsewhere. Under that registry space, I see the mount points for /, /usr/bin & /usr/lib. I do not see any drive mount points. Even if I log in as Administrator and do a 'umount -A' (or 'umount -S') which should unmount all mountpoints, the /cygdrive/{c,e} mount points still exist. I'm starting to wonder if requiring a /cygdrive/ mount point is really all that inconvenient...seeing as I can't even get rid of mine to reproduce the problem. :-/
Comment 6•22 years ago
|
||
Hi Chris : Requiring a /cygdrive/ mount point does not seem to be all that inconvenient. Maybe all that's needed here is to add this part to the build instructions?
Assignee | ||
Comment 7•22 years ago
|
||
Chak: I added a note about the /cygdrive issue to the "Common Sticking Points" of the updated win32 build instructions. Out of curiosity, what does "mount -p" return as the mount prefix for your drives? I'm still wondering where the option to change the mount prefix comes from as I haven't seen it. Was this a fresh install of cygwin or an update of a previous release (like b20.1)?
Comment 8•22 years ago
|
||
C:\WINNT> mount -p Prefix Type Flags / user textmode Here's what i remember regarding the mount stuff: 1. I had installed Cygwin a while ago (sorry i do not remember which version) 2. After the install, I had used the istructions at http://cygwin.com/faq/faq.html#SEC53 to change the mount prefix(Specifically the part which talks about "You can avoid the ambiguity of Windows paths, and avoid typing "/cygdrive", by explicitly mounting drives to posix paths". I mainly did this save myself some typing in bash windows as the note says. 3. I had to undo the part(in 2 above) to get Mozilla building with gmake per you suggestion
Comment 9•22 years ago
|
||
Just to shread a little light on the subject: Cygwin has its own mount table (as seen in the registry): $ mount C:\Cygwin\bin on /usr/bin type system (binmode) C:\Cygwin\lib on /usr/lib type system (binmode) C:\Cygwin on / type system (binmode) c: on /cygdrive/c type user (binmode,noumount) d: on /cygdrive/d type user (binmode,noumount) e: on /cygdrive/e type user (binmode,noumount) f: on /cygdrive/f type user (binmode,noumount) h: on /cygdrive/h type user (binmode,noumount) k: on /cygdrive/k type user (binmode,noumount) l: on /cygdrive/l type user (binmode,noumount) x: on /cygdrive/x type user (binmode,noumount) The /cygdrive/?/ are *not* mounted directories but Cygwin simply "map" each windows drive automatically in that directory, so that a program can access each windows file and not only "mounted" directories. /cygdrive/?/ is just a nifty 'hack', though very useful. By default it is installed in binmode, which is the right default (textmode means "by default open files ni text mode" and leads to many problems if the program doesn't use "rt" or "wt"). What is thwe problem in using always the /cygdrive/x/path method? That can be easily converted in x:\path using sed, no need to mount everyting as the /cygdrive/ tree has nothing different from "real" mounted directories... AFAIK. Anyway, I'm downloading the source so that I can test and do a better report on the problem.
Assignee | ||
Updated•22 years ago
|
Severity: blocker → major
Priority: -- → P3
Summary: build fails when using drives not mounted by cygwin → build fails if cygwin mount prefix is not /cygdrive
Target Milestone: --- → mozilla1.3beta
Assignee | ||
Comment 10•21 years ago
|
||
This patch fixes the /cygdrive assumptions in the code by checking what mount prefix is returned by 'mount -p'. It will slow down the cygwin-wrapper slightly.
Assignee | ||
Updated•21 years ago
|
Attachment #119002 -
Flags: review?(bryner)
Assignee | ||
Comment 11•21 years ago
|
||
FYI, this patch still won't fix the problem of building on a mountpoint that doesn't use the default mount prefix. That can only be fixed by calling cygpath on each individual arg. Nor will it solve the problem of building under the cygwin install point (c:\cygwin\). That problem could be fixed if cygwin make didn't auto-translate the paths used in automatic variables ($^).
Target Milestone: mozilla1.3beta → mozilla1.4beta
Comment 12•21 years ago
|
||
This is what I've had in my tree for a while and it works for me, but I've never tried it in any other environments. Have a look, and ignore this if you don't like it.
Assignee | ||
Comment 13•21 years ago
|
||
Comment on attachment 119133 [details] [diff] [review] Possible alternate approach... The only problem I see with it is that it only addresses mountprefix == /cygdrive & mountprefix == /. (Granted, those are the only ones I've tested with as well but I wouldn't be surprised if others were used.)
Updated•21 years ago
|
Attachment #119002 -
Flags: review?(bryner) → review+
Comment 14•21 years ago
|
||
In my environment, mount -p shows: $ mount -p Prefix Type Flags /cygdrive user binmode /cygdrive system binmode so mount -p | grep ^/ | awk '{ print $1 }' will get /cygdrive /cygdrive and it breaks my build. Is that a cygwin bug?
Assignee | ||
Comment 15•21 years ago
|
||
No, that's not a bug. Cygwin allows you to have separate user defined mount points as well as system defined ones. Try this patch. It should pick the first system defined mount prefix.
Comment 16•21 years ago
|
||
On my system I get this from mount -p Prefix Type Flags /cygdrive system textmode but I've got plenty more mount points than that, mount gives this: C:\cygwin\bin on /usr/bin type system (textmode) C:\cygwin\lib on /usr/lib type system (textmode) C:\cygwin on / type system (textmode) c: on /c type user (textmode) e: on /e type user (textmode) e: on /e type system (textmode) f: on /f type user (textmode) g: on /cygdrive/g type system (textmode) g: on /g type system (textmode) h: on /h type system (textmode) d: on /cygdrive/d type user (textmode,noumount)
Assignee | ||
Comment 17•21 years ago
|
||
Comment 18•21 years ago
|
||
Something about this was checked in and I suspect it broke my build. I had to manually apply the patch for nsprpub/build/cygwin-wrapper to make it build.
Assignee | ||
Comment 19•21 years ago
|
||
Bah. Apparently, some people (or maybe it's just timeless) only have a user defined mount prefix so we're taking whichever comes first.
Attachment #119184 -
Attachment is obsolete: true
Attachment #119200 -
Attachment is obsolete: true
Comment 20•21 years ago
|
||
that patch worked for me. see news://news.mozilla.org:119/3E8B4BC9.2000606@sspitzer.org
Comment 21•21 years ago
|
||
I had the same problem. This is what I used to get a build this morning. It's similar, but it's possibly a little faster since it doesn't have to add another pipe. For some reason, and I had never realized this before today, my cygwin installation has multiple base mount points, so mount -p says: $ mount -p Prefix Type Flags /cygdrive user textmode /cygdrive system binmode $ And it's still that way even after I tried rebuilding all my mount points using regedit.
Comment 22•21 years ago
|
||
Oh. looking closer: no fewer pipes in my version after all.
Comment 23•21 years ago
|
||
mount -p|awk '{if(/^\//) {print $1; exit}}'
Assignee | ||
Comment 24•21 years ago
|
||
danm, I checked in your change. Less pipes and creature hit the perl/bin/head problem. All of my boxes, which were all installed within the past 3 months, only have the single system mount prefix. jst, 'mount -p' just shows the default mount prefix used when mapping a new drive for cygwin. I'm surprised that you have a default of /cygdrive but the rest use / . I assume you changed those. You can have an many mount points as you want but I think there's only a single default mount prefix for each mount type (system & user).
Comment 25•21 years ago
|
||
FYI, this didn't fix the build problems for me. I'm still stuck with my own version of this (attachment #119133 [details] [diff] [review]), which I've lived with now for months... Maybe my mountpoints are messed up, all I did was to mount my drives as /<drive letter>, I didn't mess with the default mount prefix, didn't even know there was one. /me points out that he really doesn't like cygwin's dealings with mount points.
Assignee | ||
Comment 26•21 years ago
|
||
jst, given your mount table listed in comment #16, the checked in changes won't work for you unless you're building on drive d or g due to the reasons I pointed out in comment #11. You could have avoided mounting those drives individually by just changing the default mount prefix and rebooting.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 27•21 years ago
|
||
I am just trying to run the layout regression tests and get: C:\moz_sour\mozilla\mozilla\layout\html\tests\block>sh rtest.sh baseline testbase /cygdrive/c/moz_sour/mozilla/mozilla/layout/html/tests/block/../../../../.. Running baseline in base sed: -e expression #1, char 7: Unterminated `s' command /cygdrive/c/moz_sour/mozilla/mozilla/layout/html/tests/block/runtests.sh -m base line -f baseline backing out the changes to runtests.sh make the whole thing running again. Have you ever tested that the layout regression test did survive the change under winxx?
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•