-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Corsepius on 4/12/2007 11:17 AM:
>
> What matters is the executable bit. AFAICT, even old FAT had them.
No, FAT has no such thing. After all, we are talking about a file system
with 2 second timestamp granularity. FAT lacks the tr
On Thu, 2007-04-12 at 11:04 -0600, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Ralf Corsepius on 4/12/2007 10:43 AM:
> > On Thu, 2007-04-12 at 05:12 -0600, Eric Blake wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA1
> >>
> >> According to Ralf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Corsepius on 4/12/2007 10:43 AM:
> On Thu, 2007-04-12 at 05:12 -0600, Eric Blake wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> According to Ralf Corsepius on 4/12/2007 4:46 AM:
>>> To me this reads as: MinGW and Cyg
On Thu, 2007-04-12 at 05:12 -0600, Eric Blake wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> According to Ralf Corsepius on 4/12/2007 4:46 AM:
> > To me this reads as: MinGW and Cygwin's "test -x" are broken.
>
> Give an example where cygwin's "test -x" is broken.
RTEMS users have r
Eric Blake wrote:
> According to Ralf Corsepius on 4/12/2007 4:46 AM:
>> To me this reads as: MinGW and Cygwin's "test -x" are broken.
>
> Give an example where cygwin's "test -x" is broken. MinGW has
> problems, but in my experience, cygwin does not.
AFAIK, it has similar problems to those exper
>> As I read the background discussion, leading to introduction of this
>> extended test, it appears that it was introduced to appease one broken
>> compiler suite,
> Wrong.
>
> It was triggered by running standard autoconf-2.61 configure scripts on
> MinGW and Cygwin.
I beg to differ. The exte
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Ralf Corsepius on 4/12/2007 4:46 AM:
> To me this reads as: MinGW and Cygwin's "test -x" are broken.
Give an example where cygwin's "test -x" is broken. MinGW has problems,
but in my experience, cygwin does not.
- --
Don't work too hard
On Thu, 2007-04-12 at 10:46 +0100, Keith MARSHALL wrote:
> Ralf Corsepius wrote:
> > On Wed, 2007-04-11 at 10:32 -0700, Paul Eggert wrote:
> >> Stepan Kasal <[EMAIL PROTECTED]> writes:
> >>
> >>> * lib/autoconf/general.m4 (_AC_LINK_IFELSE): Skip
> AS_TEST_X
> >>> when cro
Ralf Corsepius wrote:
> On Wed, 2007-04-11 at 10:32 -0700, Paul Eggert wrote:
>> Stepan Kasal <[EMAIL PROTECTED]> writes:
>>
>>> * lib/autoconf/general.m4 (_AC_LINK_IFELSE): Skip
AS_TEST_X
>>> when cross-compiling.
>>
>> Thanks, I installed that.
>
> Hmm, I am not convinc
Hello,
On Thu, Apr 12, 2007 at 07:47:04AM +0200, Ralf Corsepius wrote:
> > Stepan Kasal <[EMAIL PROTECTED]> writes:
> > > * lib/autoconf/general.m4 (_AC_LINK_IFELSE): Skip AS_TEST_X
> > > when cross-compiling.
> Hmm, I am not convinced. If this check can be skipped for cross
> compilation (Wh
On Wed, 2007-04-11 at 10:32 -0700, Paul Eggert wrote:
> Stepan Kasal <[EMAIL PROTECTED]> writes:
>
> > * lib/autoconf/general.m4 (_AC_LINK_IFELSE): Skip AS_TEST_X
> > when cross-compiling.
>
> Thanks, I installed that.
Hmm, I am not convinced. If this check can be skipped for cross
compil
Stepan Kasal <[EMAIL PROTECTED]> writes:
> * lib/autoconf/general.m4 (_AC_LINK_IFELSE): Skip AS_TEST_X
> when cross-compiling.
Thanks, I installed that.
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoc
Hello,
let me return to the problem reported on Thu, Mar 29, 2007 by Chris Johns:
> The autoconf-2.61 release added a 'test -x' to AC_LINK_IFELSE and that has
> broken MinGW based cross-compilers using autoconf packages in MSYS.
>
> The change is:
>
> http://cvs.savannah.gnu.org/viewcvs/autoco
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Chris Johns on 4/1/2007 11:57 PM:
>
>> I understand that MSYS
>> has a problem, but I don't know that Cygwin does. Does Cygwin have
>> the problem? If not, then the test is incorrect.
>
> It may have the problem if the file-system is F
Paul Eggert wrote:
I want it to evaluate as false on platforms where 'test -x' doesn't
work as Posix-conforming scripts would expect.
Can we assume a chmod is present ? So on Linux:
$ set -x; touch a.out; chmod +x a.out; test -x; echo $?
+ touch a.out
+ chmod +x a.out
+ test -x
+ echo 0
0
a
Keith Marshall <[EMAIL PROTECTED]> writes:
> Thus, because of the negation in the final two tests, I would expect the
> proposed expression to evaluate as false on MSYS, and I suspect also on
> Cygwin. Is that what you want to achieve?
I want it to evaluate as false on platforms where 'test -x
Quoting Keith Marshall <[EMAIL PROTECTED]>:
On Sunday 01 April 2007 18:23, Paul Eggert wrote:
For example, will this test work? If not, why not?
test -x / && { { test -x /bin/sh && test ! -f /bin/sh.exe; } ||
test ! -f /bin/sh; }
It might. I don't have a Win32 box here, so can't verify
On Sunday 01 April 2007 18:23, Paul Eggert wrote:
> For example, will this test work? If not, why not?
>
> test -x / && { { test -x /bin/sh && test ! -f /bin/sh.exe; } ||
> test ! -f /bin/sh; }
It might. I don't have a Win32 box here, so can't verify this until I
return to work in the morni
Harlan Stenn <[EMAIL PROTECTED]> writes:
>> test -x / && { { test -x /bin/sh && test ! -f /bin/sh.exe; } || test ! -f
>> /bin/sh; }
>
> Are curly braces safe to use on Old versions of /bin/sh?
Yes.
___
Autoconf mailing list
Autoconf@gnu.org
http://li
> test -x / && { { test -x /bin/sh && test ! -f /bin/sh.exe; } || test ! -f
> /bin/sh; }
Are curly braces safe to use on Old versions of /bin/sh?
H
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
>> > if test -x / >/dev/null 2>&1; then
>> > as_test_x='test -x'
>> > else
>> > # do something frighteningly complicated and barely
>> > comprehensible # (my comment, not in actual code)...
>> >
>> as_test_x is intended to mimic test -x. Since 'test -x' succeeds
>> on searchable direct
On Saturday 31 March 2007 06:02, Paul Eggert wrote:
> Keith Marshall <[EMAIL PROTECTED]> writes:
> > While MSYS strives to provide a Unixy
> > shell, it has to work within the limitations of the underlying
> > Win32 OS, and that means the ability to identify a file as
> > executable must rely on th
Keith Marshall <[EMAIL PROTECTED]> writes:
> While MSYS strives to provide a Unixy
> shell, it has to work within the limitations of the underlying Win32
> OS, and that means the ability to identify a file as executable must
> rely on the file name extension, with the one exception of shebanged
On Fri, 2007-03-30 at 00:16 +0100, Keith Marshall wrote:
> On Thursday 29 March 2007 18:04, Ralf Wildenhues wrote:
> > * Chris Johns wrote on Thu, Mar 29, 2007 at 08:45:36AM CEST:
> > > The autoconf-2.61 release added a 'test -x' to AC_LINK_IFELSE and
> > > that has broken MinGW based cross-compile
On Friday 30 March 2007 00:38, Ralf Wildenhues wrote:
> > I'm curious as to the rationale behind this decision to insist of
> > linker output files to pass `test -x';
Reading this again, I'm appalled by my sloppy English; of course I meant
to write `...insist on linker output files passing...'.
Hello Keith,
* Keith Marshall wrote on Fri, Mar 30, 2007 at 01:16:23AM CEST:
> On Thursday 29 March 2007 18:04, Ralf Wildenhues wrote:
> > * Chris Johns wrote on Thu, Mar 29, 2007 at 08:45:36AM CEST:
> > > The autoconf-2.61 release added a 'test -x' to AC_LINK_IFELSE and
> > > that has broken MinG
On Thursday 29 March 2007 18:04, Ralf Wildenhues wrote:
> * Chris Johns wrote on Thu, Mar 29, 2007 at 08:45:36AM CEST:
> > The autoconf-2.61 release added a 'test -x' to AC_LINK_IFELSE and
> > that has broken MinGW based cross-compilers using autoconf packages
> > in MSYS.
>
> Not the one I'm using
Chris Johns <[EMAIL PROTECTED]> writes:
> Is the 'test -x' suitable for MSYS and a cross-compiler ?
Sounds like the answer is "no". Can you suggest a patch that won't
harm non-MSYS systems?
___
Autoconf mailing list
Autoconf@gnu.org
http://lists.gnu.
Hi Chris,
* Chris Johns wrote on Thu, Mar 29, 2007 at 08:45:36AM CEST:
>
> The autoconf-2.61 release added a 'test -x' to AC_LINK_IFELSE and that has
> broken MinGW based cross-compilers using autoconf packages in MSYS.
Not the one I'm using. Debian testing's cross compiler package
i586-mingw3
Hello,
The autoconf-2.61 release added a 'test -x' to AC_LINK_IFELSE and that has
broken MinGW based cross-compilers using autoconf packages in MSYS.
The change is:
http://cvs.savannah.gnu.org/viewcvs/autoconf/lib/autoconf/general.m4?root=autoconf&r1=1.931&r2=1.932
RTEMS uses AC_LINK_IFELSE
30 matches
Mail list logo
