cygwin coreutils-5.3.0-4 rm change breaks Libtool

[Robert Ögren]

Hi again,

Eric Blake wrote:
> [cc'ing bug-libtool]

Thanks. Ralf and other Libtool people: I apologize for not cc:ing you in 
the first place, I should have done that.

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

So far Libtool is the only thing for me that was affected by the change.

>> 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? 
(snip)
> 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?

I have read your later responses on this thread. If you change your mind 
and decide to keep the new rm behavior, I've realized there is a very 
simple solution for the Libtool problem: Move the rm line before the 
stuff that invokes gcc (swaps step 1 and 2 in my description above).

I'll attach a patch for the Libtool-1.5.14 sources that does this. So 
far I've only tested it by running the Libtool testsuite, but if you 
want I can run more tests. I can also test the change on the Libtool CVS 
HEAD branch if that is desirable.

(With the libtool-1.5.14 testsuite and my patch, all tests except 
build-relink2.test passes for me, but that test doesn't seem to pass 
with the old version of coreutils either)

Robert
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: libtool-1.5.14-rm-fix.patch
URL: <http://cygwin.com/pipermail/cygwin/attachments/20050413/2921ea9d/attachment.ksh>
-------------- next part --------------
--
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/