Mail Archives: cygwin/2003/04/16/01:26:31
Well, it seems that the problem described below is due in some way to
the changes in the cygwin DLL between 1.3.20 and 1.3.21. Unfortunately,
I don't have time to do a binary search right now.
I built libtool, and then ran the full test suite.
Then, I cd'd into .build/tests and ran
"make check TESTS='dryrun.test' VERBOSE=x"
(it failed, as below)
Next, I killed all cygwin processes, replaced /usr/bin/cygwin1.dll
(version 1.3.22) with [ 1.3.21 | 1.3.20 ], cranked up another bash
shell, and ran the same command again.
It failed identically with cygwin-1.3.22 and cygwin-1.3.21, but
succeeded with cygwin-1.3.20. Since that was the ONLY change between
test runs, I'm pretty sure that something in cygwin is "causing" this
problem.
(I put "causing" in quotes, because it's possible that the improvements
in cygwin are simply exposing a bug in libtool or ls.exe, I dunno)
If anybody wants to download the libtool source (1.5 is OUT!! see
forthcoming announcement) and try tracking this down, I'd be grateful.
--Chuck
Charles Wilson wrote:
> So I rebuilt libtool from CVS the other day (just to make sure it was
> still working since 1.5-final is due RSN) and ran the self tests.
>
> While it still fails the build-relink2 test and the quote test (long
> standing issues), it now fails the dry-run test. However, I can't
> figure out why.
>
> Basically, dry-run creates a build directory tree, and takes an 'ls -lR'
> snapshot of it which is stored in a file (somewhere outside the tree in
> question). Then, it runs a "dryrun" compile command (which should do
> nothing) and takes another snapshot -- the two snaps should match.
>
> (Then, it compiles "for real", takes a new 'before' snapshot, runs a
> dryrun link command, etc etc. But that's not important.)
>
> Here's the failure:
>
> -----------BEFORE 'SNAPSHOT'------------
> .:
> total 163
> -rw-rw-r-- 1 cwilson None 20124 Apr 9 01:58 Makefile
> -rw-rw-r-- 1 cwilson None 31500 Apr 9 01:58 config.log
> -rwxrwxr-x 1 cwilson None 28943 Apr 9 01:58 config.status
> -rwxrwxr-x 1 cwilson None 210074 Apr 9 03:05 libtool
> -rw-rw-r-- 2 cwilson None 18715 Apr 9 03:05 main.o
>
> .libs:
> total 206
> -rwxrwxr-x 1 cwilson None 210074 Apr 9 03:03 libtool
> drwxrwxr-x+ 3 cwilson None 0 Apr 9 03:05 temp
> -----------BEFORE 'SNAPSHOT'------------
>
> ------------AFTER 'SNAPSHOT'------------
> .:
> total 305
> -rw-rw-r-- 1 cwilson None 20124 Apr 9 01:58 Makefile
> -rw-rw-r-- 1 cwilson None 31500 Apr 9 01:58 config.log
> -rwxrwxr-x 1 cwilson None 28943 Apr 9 01:58 config.status
> -rwxrwxr-x 1 cwilson None 210074 Apr 9 03:05 libtool
> -rw-rw-r-- 2 cwilson None 18715 Apr 9 03:05 main.o
>
> .libs:
> total 206
> -rwxrwxr-x 1 cwilson None 210074 Apr 9 03:03 libtool
> drwxrwxr-x+ 3 cwilson None 0 Apr 9 03:05 temp
> ------------AFTER 'SNAPSHOT'------------
>
> The only difference is the "total usage" line that 'ls' prints. In the
> before snapshot, it says "total 163" (kB). Adding the individual file
> sizes, that is clearly wrong. The after snapshot gets it right: "total
> 305" (kB) is the sum of the individual file sizes (which are the same as
> in the before snapshot).
>
> This looks like a race condition or something in cygwin or
> fileutils(ls.exe). Has anybody seen anything like this, or is there a
> known file-system-related race in cygwin 1.3.22?
>
> Thanks for any input...
>
> --Chuck
>
>
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -