Re: 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

--- libtool-1.5.14.orig/ltmain.in       2005-02-12 13:18:34.000000000 +0100
+++ libtool-1.5.14/ltmain.in    2005-04-13 21:58:51.984375000 +0200
@@ -4667,10 +4667,13 @@
          *cygwin*)
            exeext=.exe
            outputname=`$echo $outputname|${SED} 's,.exe$,,'` ;;
          *) exeext= ;;
        esac
+
+       $rm $output
+
        case $host in
          *cygwin* | *mingw* )
            cwrappersource=`$echo ${objdir}/lt-${outputname}.c`
            cwrapper=`$echo ${output}.exe`
            $rm $cwrappersource $cwrapper
@@ -4880,11 +4883,10 @@
          # Since the "real" binary is built for $host, then this
          # wrapper might as well be built for $host, too.
          $run $LTCC -s -o $cwrapper $cwrappersource
          ;;
        esac
-       $rm $output
        trap "$rm $output; exit $EXIT_FAILURE" 1 2 15
 
        $echo > $output "\
 #! $SHELL