[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Robert Ögren
Subject: Re: cygwin coreutils-5.3.0-4 rm change breaks Libtool
Date: Wed, 13 Apr 2005 23:44:20 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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?
Which line?  Since you already found the culprit, pointing others to
the location would be helpful.  Can you come up with a simple libtool

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)

--- 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 @@
            outputname=`$echo $outputname|${SED} 's,.exe$,,'` ;;
          *) exeext= ;;
+       $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
-       $rm $output
        trap "$rm $output; exit $EXIT_FAILURE" 1 2 15
        $echo > $output "\
 #! $SHELL

reply via email to

[Prev in Thread] Current Thread [Next in Thread]