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.
>> 3. libtool creates "output"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)
(snip)
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 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
-- 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/
