Re: cygwin coreutils-5.3.0-4 rm change breaks Libtool

[ericblake at comcast dot net (Eric Blake)]

[cc'ing bug-libtool]

> Hi everybody,
> 
> the change in rm semantics, implicit .exe handling, in coreutils-5.3.0-4 
> breaks Libtool (1.5.10, and some later versions). More specifically, 
> when Libtool is used to link an executable which requires a wrapper 
> script to handle uninstalled libraries, the corresponding wrapper .exe 
> is now incorrectly removed (but not the script without the .exe 
> extension).

Thanks for the accurate report.

When I added implicit .exe handling to rm in the latest cygwin release, I did not realize that any program would be depending on the previous semantics.  It would be nicer if we could keep the .exe handling in rm, to keep symmetry with the handling done in mv, cp, install, etc.  Is there anything else in cygwin besides libtool depending on the old semantics, where in a directory with foo.exe but not foo, `ls foo' succeeds but `rm foo' fails?  If other cases are found, then I will probably have to release a coreutils-5.3.0-5 for cygwin that removes the implicit .exe behavior for rm (or a patch that adds a cygwin-specific flag that can suppress the .exe handling at will), but I'd rather see libtool patched if it is the only program affected.

To some degree, the problem isn't even coreutils fault - cygwin itself is where it was decided that stat(2) succeeds for either "foo" or "foo.exe" when only "foo.exe" exists, but that unlink(2) fails unless it is spelled "foo.exe".  The implicit .exe magic I added in rm is simply recognizing that if stat succeeded but unlink failed, that unlink should be tried a second time with the correct extension.

> What happens in libtool is this:
> 
> 1. gcc is used to create "output.exe"
> 2. rm is used to remove "output"   (the script, without .exe, but now 
> this removes the .exe instead)
> 3. libtool creates "output"
> 
> I think the problem only occurs if the build directory is clean so that 
> there is no old output script lying around.

Is there any way to patch libtool to check whether the script exists before trying to remove it?  One possible approach that works with current cygwin, whether using coreutils 5.3.0 cygwin patchlevel 3 (`rm foo' fails) or 4 (`rm foo' removes foo.exe if no foo exists):

$ touch x y y.exe z.exe
$ ls x y z
x  y  z
$ ls x* y* z*
x  y  y.exe  z.exe
$ touch foo.exe
$ ls foo
foo
$ ls [f]oo
ls: [f]oo: No such file or directory

Shell globbing relies on readdir(2), which, unlike stat, does not lie about file extensions.  So, libtool could use shell globbing to determine the correct spelling of the existing filename to decide whether rm should be applied.  The problem spot is already local to cygwin, but it would be nice to have it in the upstream libtool sources.

> 
> The easiest way to reproduce the problem is to run the Libtool 
> testsuite, for example by uninstalling Cygwin's Libtool and installing 
> the libtool-1.5.14 tarball. Run the Libtool testcases with "make check" 
> and you will notice several SKIPs because of missing .exes, which 
> doesn't happen with older coreutils.
> 
> The problem also occurs with a very recent Libtool HEAD from CVS.
> 
> Working around the problem isn't hard, just comment out the offending rm 
> line in Libtool's ltmain.sh,

Which line?  Since you already found the culprit, pointing others to the location would be helpful.  Can you come up with a simple libtool patch?

> or downgrade to coreutils-5.3.0-3. It 
> shouldn't be that hard to make a proper change for this in Libtool if 
> the rm change is here to stay.
> 

--
Eric Blake



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