Okay, I think I've figured this out and it's a relatively undocumented
aspect of our win builds (from what I can tell).
The third_party/cygwin install we have has a modified version of
cygwin1.dll , which has been patched to tell cygwin the root is
third_party/cygwin rather than /. In order for
On Mon, Jul 6, 2009 at 6:31 PM, Dirk Pranke dpra...@google.com wrote:
We should probably change run_layout_tests to automatically run this
script prior to running the regression (running it every time should
be harmless).
Patches are welcome!
M-A
Okay, I think I've figured this out and it's a relatively undocumented
aspect of our win builds (from what I can tell).
The third_party/cygwin install we have has a modified version of
cygwin1.dll , which has been patched to tell cygwin the root is
third_party/cygwin rather than /. In order for
2009/7/6 David Jones ds...@163.com:
Okay, I think I've figured this out and it's a relatively undocumented
aspect of our win builds (from what I can tell).
The third_party/cygwin install we have has a modified version of
cygwin1.dll , which has been patched to tell cygwin the root is
That's really weird, as I posted, between the two same layout-tests, one
succeeded on XP of my notebook, one failed on XP of my PC.
I totally agree with you, I think that must be something wrong about
ENVIROMENT, such as PATH.
FYI:
my PATH=D:\Program Files\Perl\bin;D:\Program
Debugging this a bit more ... it seems to be some sort of XP vs. Vista
thing. If I run wdiff exp.txt act.txt in a bash shell or a command
prompt on Vista, it works. On XP, it works in a bash shell, but in a
command prompt, I get the /tmp error. It looks like XP is expecting
to find the cygwin
Hi Marc-Antoine,
I am getting the same wdiff: /tmp/t101c.0: No such file or directory
errors ... I'm running an XP VM on a Vista 64 host, but I've tried
both local files (running the tests on a virtual drive) as well as a
network share to the host VM. I've tried the /etc/fstab, the
Well,new headway is I found it's really a weird bug. I copies the same source
from my pc to my notebook(both are Windows XP), and run layouttest.
The one on pc is still with the cygwin errors I've posted, but the notebook's
succeeded without any cygwin error.
I cann't explain that, could
Just guessing, access controls. Assuming you are an administrator on your
workstation, try:
- Right click on src, Properties
- Security tab
- Advanced button
- Owner tab
- Select your account, check Replace owner on subcontainers and objects,
Click OK and wait
- Click OK again to dismiss all the
I wasn't either, but a simple search provided this:
:: Set CYGWIN variable to 'nontsec'. That makes sure that permissions
:: on your windows machine are not updated as a side effect of cygwin::
operations.SET CYGWIN=nontsec
well, where to set it? in the run_webkit_tests.bat?
If you're hitting overflows, it might be from the native client landing,
which ended up dragging in more than intended, its been backed out, but it
was an extra 300MB.
gyp should be setting CYGWIN=nontsec for actions and rules (unless you use
the msvs_use_cygwin_shell:0).
-BradN
2009/7/1 David
It looks like it had trouble writing to /tmp. I don't think there are
missing binaries, looks like a space/permission issue. Is there enough
space available?
2009/6/29 David Jones ds...@163.com
I reviewed my layout-tests' output, and found some errors like:
090629 14:28:30 __init__.py:1032
I have the same problem when running the layout tests from WinXP inside a
VMware image. My host machine is a Vista64 box. I haven't been able to
track down the problem, so I'm hopeful that someone else might also know the
fix :-)
-Darin
2009/6/30 John Abd-El-Malek j...@chromium.org
It looks
set CYGWIN=nontsec
?
2009/6/30 Darin Fisher da...@chromium.org:
I have the same problem when running the layout tests from WinXP inside a
VMware image. My host machine is a Vista64 box. I haven't been able to
track down the problem, so I'm hopeful that someone else might also know the
fix
14 matches
Mail list logo
