Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <425D92B4.30003@roboros.com> Date: Wed, 13 Apr 2005 23:44:20 +0200 From: =?ISO-8859-1?Q?Robert_=D6gren?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) MIME-Version: 1.0 To: Eric Blake CC: cygwin AT cygwin DOT com, bug-libtool AT gnu DOT org Subject: Re: cygwin coreutils-5.3.0-4 rm change breaks Libtool References: <041220052251 DOT 26916 DOT 425C50E800071C000000692422007507840A050E040D0C079D0A AT comcast DOT net> In-Reply-To: <041220052251.26916.425C50E800071C000000692422007507840A050E040D0C079D0A@comcast.net> Content-Type: multipart/mixed; boundary="------------000600020000040104030608" X-IsSubscribed: yes --------------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--