[ This is a Libtool bug. It is better discussed on the bug-libtool
mailing list. I am Cc'ing that list. Please remove the autoconf
list from further resposes, thankyou. ]
* Ray Lehtiniemi wrote on Tue, Jan 11, 2005 at 08:52:47PM CET:
>
> i am having difficulty with my cross-development setup.
> Cc: bug-texinfo@gnu.org, autoconf@gnu.org
> From: Ben Pfaff <[EMAIL PROTECTED]>
> Date: Fri, 21 Jan 2005 08:58:39 -0800
>
> >> I have had Windows systems refuse to execute .exe files that were
> >> mounted off a NetApp until I switched over to a Unix system and
> >> did a chmod +x.
> >
> > This
On Sat, Jan 22, 2005 at 10:45:00AM +0200, Eli Zaretskii wrote:
> AFAIK, Windows doesn't have the
> notion of a file being executable
That may be true of e.g. Windows 95/98, but Windows NT and progeny do record an
execute permission. If you remove it from the ACLs
Hello,
let me post a summary of the thread ``AS_EXECUTABLE_P again'' which
I started on the autoconf list:
I proposed to change the implementation of AS_EXECUTABLE_P on platforms
supporting `test -x' from
test -f $1 && test -x $1
to
test -x $1 && test ! -d $1
But Paul has pointed o
On Sat, 22 Jan 2005, Eli Zaretskii wrote:
There was no special network software installed on the machine in
question.
Then what is NetApp?
The "NetApp" referred to is a network server from Network Appliance,
Inc. (see http://www.networkappliance.com/). Servers from Network
Appliance use their ow
> Date: Sat, 22 Jan 2005 16:30:07 +0100
> From: Stepan Kasal <[EMAIL PROTECTED]>
> Cc: Eric Blake <[EMAIL PROTECTED]>, autoconf@gnu.org, bug-texinfo@gnu.org
>
> I proposed to change the implementation of AS_EXECUTABLE_P on platforms
> supporting `test -x' from
>test -f $1 && test -x $1
> t
Hello,
On Sat, Jan 22, 2005 at 06:23:25PM +0200, Eli Zaretskii wrote:
> > I proposed to change the implementation of AS_EXECUTABLE_P on platforms
> > supporting `test -x' from
> >test -f $1 && test -x $1
> > to
> >test -x $1 && test ! -d $1
> >
> > But Paul has pointed out the cha
> Date: Sat, 22 Jan 2005 17:57:44 +0100
> From: Stepan Kasal <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], autoconf@gnu.org, bug-texinfo@gnu.org
>
> If there was a named pipe /tmp/foo with an executable bit set, the test
> could misclasify it as an executable file.
Thanks for the explanations.
FW
I have a code package I'm trying to port where I ran autoconf to
customize, but then found it did not update these local.mak includes for
Makefiles (which held the target objects). It seems there is a
build_init script in the code I picked up, which would recurse the
source tree and update the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eli Zaretskii on 1/22/2005 9:23 AM:
>>2) On Cygwin, both `test -x foo' and `test -f foo' look for foo.exe.
>
> That's a bug, IMHO.
It's actually a design decision, and seems correct to me. As -x applies
to more than just executables (fo
Jeff Stevens wrote:
I have a code package I'm trying to port where I ran autoconf to
customize, but then found it did not update these local.mak includes for
Makefiles (which held the target objects). It seems there is a
build_init script in the code I picked up, which would recurse the
source
> Date: Sat, 22 Jan 2005 19:51:06 -0700
> From: Eric Blake <[EMAIL PROTECTED]>
> CC: Stepan Kasal <[EMAIL PROTECTED]>, autoconf@gnu.org, bug-texinfo@gnu.org
>
> >>2) On Cygwin, both `test -x foo' and `test -f foo' look for foo.exe.
> >
> > That's a bug, IMHO.
>
> It's actually a design decisio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eli Zaretskii on 1/22/2005 9:46 PM:
>
> Then how can I, with the Cygwin Bash, make a reliable test for the
> existence of `foo'? Suppose that `foo' doesn't exist, but `foo.exe'
> does--how can one test for that?
If only `foo.exe' exists
13 matches
Mail list logo
