* Robert Ögren wrote on Wed, Apr 13, 2005 at 11:44:20PM CEST:
>
> 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
Hi Eric,
* Eric Blake wrote on Wed, Apr 13, 2005 at 03:24:15PM CEST:
> According to Ralf Wildenhues on 4/13/2005 1:17 AM:
> >
> > Hmm. Here you talk about the superficial symmetry in mv/cp vs rm..
>
> Only rm was given new .exe magic. cygwin mv and cp have had them for
> several years, before
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 speci
On Apr 13 07:24, Eric Blake wrote:
> As a side note, when POSIX requires atomicity of a syscall and cygwin
> can't provide it with respect to Windows, would it at least be possible to
> provide atomicity with respect to other cygwin programs via an
> interprocess mutex managed by cygwin1.dll? Or i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Wildenhues on 4/13/2005 1:17 AM:
>
> Hmm. Here you talk about the superficial symmetry in mv/cp vs rm..
Only rm was given new .exe magic. cygwin mv and cp have had them for
several years, before coreutils was even bundled as part
Original Message
>From: Wolfgang Rieger
>Sent: 13 April 2005 08:57
> From: cygwin-ownerHcygwin.com
[mailto:cygwin-ownerHcygwin.com]
> Sent: Mittwoch, 13. April 2005 03:50
> To: cygwinHcygwin.com
> Subject: cygwin Digest 13 Apr 2005 01:49:36 -
Hi Eric, others,
* Eric Blake wrote on Wed, Apr 13, 2005 at 12:51:20AM CEST:
> [cc'ing bug-libtool]
Thanks for doing this. Note that we were planning to get another 1.5.x
point release out this or next weekend. Might be nice to have a fix in
there.
Some food for thought:
> > the change in rm
On Tue, Apr 12, 2005 at 08:52:22PM -0600, Eric Blake wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA1
>
>According to Christopher Faylor on 4/12/2005 5:44 PM:
>>On Tue, Apr 12, 2005 at 10:51:20PM +, Eric Blake wrote:
>>
>>>To some degree, the problem isn't even coreutils fault - cygwin it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Christopher Faylor on 4/12/2005 5:44 PM:
> On Tue, Apr 12, 2005 at 10:51:20PM +, Eric Blake wrote:
>
>>To some degree, the problem isn't even coreutils fault - cygwin itself
>>is where it was decided that stat(2) succeeds for either "
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Charles Wilson on 4/12/2005 7:33 PM:
> Eric Blake wrote:
>
>> 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 know where. A
Eric Blake wrote:
Working around the problem isn't hard, just comment out the offending rm
line in Libtool's ltmain.sh,
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 know where. Actually, I'd pr
On Tue, Apr 12, 2005 at 10:51:20PM +, Eric Blake wrote:
>To some degree, the problem isn't even coreutils fault - cygwin itself
>is where it was decided that stat(2) succeeds for either "foo" or
>"foo.exe" when only "foo.exe" exists, but that unlink(2) fails unless
>it is spelled "foo.exe". Th
[cc'ing bug-libtool]
> Hi everybody,
>
> 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 librarie
13 matches
Mail list logo
