This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libtool, failing dryrun test


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]