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

[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