Mail Archives: cygwin/2005/04/13/17:44:12
--------------000600020000040104030608
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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
--------------000600020000040104030608
Content-Type: text/plain;
name="libtool-1.5.14-rm-fix.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="libtool-1.5.14-rm-fix.patch"
--- 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
--------------000600020000040104030608
Content-Type: text/plain; charset=us-ascii
--
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/
--------------000600020000040104030608--
- Raw text -