AC_PROG_CC_C_O doesn't work with VC++

[Harald Dunkel-2]

Hi folks,

It seems that AC_PROG_CC_C_O does not work with Microsoft's
Visual C++ 13.10.3077. The compiler accepts command lines
like

        cl -c -o conftest.obj conftest.c

but command lines like

        cl -c -o somedir/conftest.obj conftest.c
or
        cl -c -o xyz.obj conftest.c

do not work as expected. cl silently ignores the -o
option if there is a -c.

How can I tell autoconf to not use -c and -o together,
regardless what the test said?


Regards

Harri


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Stepan Kasal]

Hello,

On Fri, Jul 01, 2005 at 10:14:28AM +0200, Harald Dunkel wrote:
> It seems that AC_PROG_CC_C_O does not work with Microsoft's
> Visual C++ 13.10.3077.
[...]
> cl -c -o somedir/conftest.obj conftest.c
> or
> cl -c -o xyz.obj conftest.c
>
> do not work as expected. cl silently ignores the -o
> option if there is a -c.

the patch attached to this mail (relative to current autoconf CVS)
should fix it.

OK to commit?

> How can I tell autoconf to not use -c and -o together,
> regardless what the test said?

Do I guess correctly that you in fact use AM_PROG_CC_C?
Then the following hack should work:

AC_PROG_CC_C_O
eval ac_cv_prog_cc_${ac_cc}_c_o=no
AM_PROG_CC_C_O

(The configure output still says that -c -o works, and NO_MINUS_C_MINUS_O
is not defined in your config.h, but it doesn't matter.)

Have a nice day,
        Stepan

2005-07-01  Stepan Kasal  <kasal@...>

        * lib/autoconf/c.m4 (AC_PROG_CC_C_O): Use conf$$.o instead of
        conftest.o, to see whether the compiler really obeys; rm the
        object file before the test.
        * lib/autoconf/fortran.m4 (_AC_PROG_FC_C_O): Likewise.

Index: lib/autoconf/c.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/c.m4,v
retrieving revision 1.201
diff -u -r1.201 c.m4
--- lib/autoconf/c.m4 24 May 2005 07:29:57 -0000 1.201
+++ lib/autoconf/c.m4 1 Jul 2005 10:43:07 -0000
@@ -585,17 +585,19 @@
 # Make sure it works both with $CC and with simple cc.
 # We do the test twice because some compilers refuse to overwrite an
 # existing .o file with -o, though they will create one.
-ac_try='$CC -c conftest.$ac_ext -o conftest.$ac_objext >&AS_MESSAGE_LOG_FD'
+ac_try='$CC -c conftest.$ac_ext -o conf$[$].$ac_objext >&AS_MESSAGE_LOG_FD'
+rm -f conf$[$]*
 if AC_TRY_EVAL(ac_try) &&
-   test -f conftest.$ac_objext && AC_TRY_EVAL(ac_try);
+   test -f conf$[$].$ac_objext && AC_TRY_EVAL(ac_try);
 then
   eval ac_cv_prog_cc_${ac_cc}_c_o=yes
   if test "x$CC" != xcc; then
     # Test first that cc exists at all.
     if AC_TRY_COMMAND(cc -c conftest.$ac_ext >&AS_MESSAGE_LOG_FD); then
-      ac_try='cc -c conftest.$ac_ext -o conftest.$ac_objext >&AS_MESSAGE_LOG_FD'
+      ac_try='cc -c conftest.$ac_ext -o conf$[$].$ac_objext >&AS_MESSAGE_LOG_FD'
+      rm -f conf$[$]*
       if AC_TRY_EVAL(ac_try) &&
- test -f conftest.$ac_objext && AC_TRY_EVAL(ac_try);
+ test -f conf$[$].$ac_objext && AC_TRY_EVAL(ac_try);
       then
  # cc works too.
  :
@@ -608,7 +610,7 @@
 else
   eval ac_cv_prog_cc_${ac_cc}_c_o=no
 fi
-rm -f conftest*
+rm -f conftest* conf$[$]*
 ])dnl
 if eval "test \"`echo '$ac_cv_prog_cc_'${ac_cc}_c_o`\" = yes"; then
   AC_MSG_RESULT([yes])
Index: lib/autoconf/fortran.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/fortran.m4,v
retrieving revision 1.194
diff -u -r1.194 fortran.m4
--- lib/autoconf/fortran.m4 30 Jun 2005 12:59:15 -0000 1.194
+++ lib/autoconf/fortran.m4 1 Jul 2005 10:43:07 -0000
@@ -461,15 +461,16 @@
 [AC_LANG_CONFTEST([AC_LANG_PROGRAM([])])
 # We test twice because some compilers refuse to overwrite an existing
 # `.o' file with `-o', although they will create one.
-ac_try='$[]_AC_FC[] $[]_AC_LANG_PREFIX[]FLAGS -c conftest.$ac_ext -o conftest.$ac_objext >&AS_MESSAGE_LOG_FD'
+ac_try='$[]_AC_FC[] $[]_AC_LANG_PREFIX[]FLAGS -c conftest.$ac_ext -o conf$[$].$ac_objext >&AS_MESSAGE_LOG_FD'
+rm -f conf$[$]*
 if AC_TRY_EVAL(ac_try) &&
-     test -f conftest.$ac_objext &&
+     test -f conf$[$].$ac_objext &&
      AC_TRY_EVAL(ac_try); then
   ac_cv_prog_[]_AC_LANG_ABBREV[]_c_o=yes
 else
   ac_cv_prog_[]_AC_LANG_ABBREV[]_c_o=no
 fi
-rm -f conftest*])
+rm -f conftest* conf$[$]*])
 if test $ac_cv_prog_[]_AC_LANG_ABBREV[]_c_o = no; then
   AC_DEFINE([]_AC_FC[]_NO_MINUS_C_MINUS_O, 1,
             [Define to 1 if your Fortran compiler doesn't accept

_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Paul Eggert]

Stepan Kasal <kasal@...> writes:

> 2005-07-01  Stepan Kasal  <kasal@...>
>
> * lib/autoconf/c.m4 (AC_PROG_CC_C_O): Use conf$$.o instead of
> conftest.o, to see whether the compiler really obeys; rm the
> object file before the test.
> * lib/autoconf/fortran.m4 (_AC_PROG_FC_C_O): Likewise.

That looks good, except for one thing: the command

  rm -f conf$$*

might remove a bit too much.  For example, if $$ = 2, it's equivalent
to "rm -f conf2*", which might remove conf23.o.  It's a small point,
but I'd feel a bit better if you uniformly replaced "conf$$" by
"conf$$t" to prevent unexpected matches like that.

[Stepan Kasal]

Hi,

On Fri, Jul 01, 2005 at 11:34:09AM -0700, Paul Eggert wrote:
> > * lib/autoconf/c.m4 (AC_PROG_CC_C_O): Use conf$$.o instead of
...
> That looks good, except for one thing: the command

OK, I'll fix the patch before committing it.

>   rm -f conf$$*
>
> might remove a bit too much.  For example, if $$ = 2, it's equivalent
> to "rm -f conf2*", which might remove conf23.o.  It's a small point,
> but I'd feel a bit better if you uniformly replaced "conf$$" by
> "conf$$t" to prevent unexpected matches like that.

The main problem is in the trap defined in ./lib/autoconf/general.m4
in _AC_INIT_PREPARE:

        rm -f -r conftest* confdefs* conf$[$]* $ac_clean_files

What should be done with this?  Should I rename this and all occurences in
the autoconf tree?

I suggest conf$$.* instead of conf$$t*; I guess it is more likely to catch
current usages.

        Stepan


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Harald Dunkel-2]

Stepan Kasal wrote:
> Hello,
>
> On Fri, Jul 01, 2005 at 10:14:28AM +0200, Harald Dunkel wrote:
>
>>How can I tell autoconf to not use -c and -o together,
>>regardless what the test said?
>
>
> Do I guess correctly that you in fact use AM_PROG_CC_C?

AM_PROG_CC_C_O. Yup.

> Then the following hack should work:
>
> AC_PROG_CC_C_O
> eval ac_cv_prog_cc_${ac_cc}_c_o=no
> AM_PROG_CC_C_O
>

This did not work. There is still -c and -o on the same
compiler command line.


Regards

Harri


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Paul Eggert]

Stepan Kasal <kasal@...> writes:

> The main problem is in the trap defined in ./lib/autoconf/general.m4
> in _AC_INIT_PREPARE:
>
> rm -f -r conftest* confdefs* conf$[$]* $ac_clean_files

How about if you simply remove conf[0-9]* instead?  Those file names
are all reserved by Autoconf anyway.  And it's more consistent to
always remove all of them, instead of removing some hard-to-explain
subset.


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Stepan Kasal]

Hello,

On Mon, Jul 04, 2005 at 11:52:38AM -0700, Paul Eggert wrote:
> > rm -f -r conftest* confdefs* conf$[$]* $ac_clean_files
>
> How about if you simply remove conf[0-9]* instead?  Those file names
> are all reserved by Autoconf anyway.  And it's more consistent to
> always remove all of them, instead of removing some hard-to-explain
> subset.

yes, this sounds good.

But when we got that far, is there any reason why Autoconf tests should
use conf$$*?  Isn't conf2.obj or conftest2.obj cleaner?

(I know, with conftest2.* one has to carefully think about 8.3 systems.)

Stepan


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Paul Eggert]

Stepan Kasal <kasal@...> writes:

> But when we got that far, is there any reason why Autoconf tests should
> use conf$$*?  Isn't conf2.obj or conftest2.obj cleaner?

You could talk me into that, yes, though it's a more global change.


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Harald Dunkel-2]

Hi folks,

Stepan Kasal wrote:
>
> the patch attached to this mail (relative to current autoconf CVS)
> should fix it.
>
> OK to commit?
>

It seems that this patch is still not in CVS. And since the
suggested workaround doesn't workaround I am stuck :-(.

Any help would be highly appreciated.


Regards

Harri


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Stepan Kasal]

Hello Harald,

On Mon, Oct 24, 2005 at 10:35:25AM +0200, Harald Dunkel wrote:
> It seems that this patch is still not in CVS. And since the
> suggested workaround doesn't workaround I am stuck :-(.

I apologize.  I have committed a patch which should fix your problem.
(Attached.)

A question: is there any reason to use  rm -f conftst2.*
instead of  rm -f conftst2.$ac_objext
Is there any C, Fortran, or F77 compiler which could create other
conftst2.* files if it receives  -o conftst2.$ac_objext ?

Have a nice day,
        Stepan

2005-10-24  Stepan Kasal  <kasal@...>

        * lib/autoconf/c.m4 (AC_PROG_CC_C_O): Use conftst2.o instead of
        conftest.o, to see whether the compiler really obeys; rm the object
        file before and after the test and register it with ac_clean_files.
        * lib/autoconf/fortran.m4 (_AC_PROG_FC_C_O): Likewise.

Index: lib/autoconf/c.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/c.m4,v
retrieving revision 1.204
diff -u -r1.204 c.m4
--- lib/autoconf/c.m4 19 Oct 2005 22:35:52 -0000 1.204
+++ lib/autoconf/c.m4 24 Oct 2005 10:26:22 -0000
@@ -576,20 +576,24 @@
       sed 's/[[^a-zA-Z0-9_]]/_/g;s/^[[0-9]]/_/'`
 AC_CACHE_VAL(ac_cv_prog_cc_${ac_cc}_c_o,
 [AC_LANG_CONFTEST([AC_LANG_PROGRAM([])])
+ac_clean_files_save=$ac_clean_files
+ac_clean_files="$ac_clean_files conftst2.$ac_objext"
 # Make sure it works both with $CC and with simple cc.
 # We do the test twice because some compilers refuse to overwrite an
 # existing .o file with -o, though they will create one.
-ac_try='$CC -c conftest.$ac_ext -o conftest.$ac_objext >&AS_MESSAGE_LOG_FD'
+ac_try='$CC -c conftest.$ac_ext -o conftst2.$ac_objext >&AS_MESSAGE_LOG_FD'
+rm -f conftst2.$ac_objext
 if AC_TRY_EVAL(ac_try) &&
-   test -f conftest.$ac_objext && AC_TRY_EVAL(ac_try);
+   test -f conftst2.$ac_objext && AC_TRY_EVAL(ac_try);
 then
   eval ac_cv_prog_cc_${ac_cc}_c_o=yes
   if test "x$CC" != xcc; then
     # Test first that cc exists at all.
     if AC_TRY_COMMAND(cc -c conftest.$ac_ext >&AS_MESSAGE_LOG_FD); then
-      ac_try='cc -c conftest.$ac_ext -o conftest.$ac_objext >&AS_MESSAGE_LOG_FD'
+      ac_try='cc -c conftest.$ac_ext -o conftst2.$ac_objext >&AS_MESSAGE_LOG_FD'
+      rm -f conftst2.$ac_objext
       if AC_TRY_EVAL(ac_try) &&
- test -f conftest.$ac_objext && AC_TRY_EVAL(ac_try);
+ test -f conftst2.$ac_objext && AC_TRY_EVAL(ac_try);
       then
  # cc works too.
  :
@@ -602,7 +606,8 @@
 else
   eval ac_cv_prog_cc_${ac_cc}_c_o=no
 fi
-rm -f conftest*
+rm -f conftest* conftst2.$ac_objext
+ac_clean_files=$ac_clean_files_save
 ])dnl
 if eval "test \"`echo '$ac_cv_prog_cc_'${ac_cc}_c_o`\" = yes"; then
   AC_MSG_RESULT([yes])
Index: lib/autoconf/fortran.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/fortran.m4,v
retrieving revision 1.195
diff -u -r1.195 fortran.m4
--- lib/autoconf/fortran.m4 10 Jul 2005 16:02:44 -0000 1.195
+++ lib/autoconf/fortran.m4 24 Oct 2005 10:26:23 -0000
@@ -459,17 +459,22 @@
 AC_CACHE_CHECK([whether $[]_AC_FC[] understands -c and -o together],
                [ac_cv_prog_[]_AC_LANG_ABBREV[]_c_o],
 [AC_LANG_CONFTEST([AC_LANG_PROGRAM([])])
+ac_clean_files_save=$ac_clean_files
+ac_clean_files="$ac_clean_files conftst2.$ac_objext"
 # We test twice because some compilers refuse to overwrite an existing
 # `.o' file with `-o', although they will create one.
-ac_try='$[]_AC_FC[] $[]_AC_LANG_PREFIX[]FLAGS -c conftest.$ac_ext -o conftest.$ac_objext >&AS_MESSAGE_LOG_FD'
+ac_try='$[]_AC_FC[] $[]_AC_LANG_PREFIX[]FLAGS -c conftest.$ac_ext -o conftst2.$ac_objext >&AS_MESSAGE_LOG_FD'
+rm -f conftst2.$ac_objext
 if AC_TRY_EVAL(ac_try) &&
-     test -f conftest.$ac_objext &&
+     test -f conftst2.$ac_objext &&
      AC_TRY_EVAL(ac_try); then
   ac_cv_prog_[]_AC_LANG_ABBREV[]_c_o=yes
 else
   ac_cv_prog_[]_AC_LANG_ABBREV[]_c_o=no
 fi
-rm -f conftest*])
+rm -f conftest* conftst2.$ac_objext
+ac_clean_files=$ac_clean_files_save
+])
 if test $ac_cv_prog_[]_AC_LANG_ABBREV[]_c_o = no; then
   AC_DEFINE([]_AC_FC[]_NO_MINUS_C_MINUS_O, 1,
             [Define to 1 if your Fortran compiler doesn't accept

[Harald Dunkel-2]

Hi Stepan,

Stepan Kasal wrote:

> Hello Harald,
>
> On Mon, Oct 24, 2005 at 10:35:25AM +0200, Harald Dunkel wrote:
>
>>It seems that this patch is still not in CVS. And since the
>>suggested workaround doesn't workaround I am stuck :-(.
>
>
> I apologize.  I have committed a patch which should fix your problem.
> (Attached.)
>

I tried the previous patch you had sent some time ago (the
version with 'conf$[$]'). But this didn't work for Bill's
cl.exe. The generated Makefile still uses -c and -o on the same
command line. I had verified that the new code is in configure.

The generated config.log says

        configure:4747: checking whether cl and cc understand -c and -o together
        configure:4779: cl -c conftest.c -o conf1504.obj >&5
        Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
        Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
 
        conftest.c
        configure:4782: $? = 0
        configure:4829: result: no

Yet the generated Makefile contains

hello-main.obj: main.c
        source='main.c' object='hello-main.obj' libtool=no \
        DEPDIR=$(DEPDIR) $(CCDEPMODE) $(depcomp) \
        $(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(hello_CPPFLAGS) \
        $(CPPFLAGS) $(AM_CFLAGS) $(CFLAGS) -c -o hello-main.obj `IFS=:; x=':$(VPATH)'; for d in $$x; do test -n $$d && d=$$d/; test -f $$d'main.c' && $(CYGPATH_W) $$d && break; done`'main.c'

The object file is created, but it is not called "hello-main.obj".

Can I post a testcase here? It would be about 100KByte, so I
should ask first. (Its so big, because it includes the
configure script and the Makefile generated on Windows.)


Regards

Harri


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Ralf Wildenhues]

Hi Harald,

* Harald Dunkel wrote on Mon, Oct 24, 2005 at 02:19:53PM CEST:
>
> I tried the previous patch you had sent some time ago (the
> version with 'conf$[$]'). But this didn't work for Bill's
> cl.exe. The generated Makefile still uses -c and -o on the same
> command line. I had verified that the new code is in configure.

Yes, but $(CC) should be set to something like
 CC = compile cl

and the `compile' script should take care of `-o'.

> The generated config.log says
>
> configure:4747: checking whether cl and cc understand -c and -o together
> configure:4779: cl -c conftest.c -o conf1504.obj >&5
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
> Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.
>  
> conftest.c
> configure:4782: $? = 0
> configure:4829: result: no
>
> Yet the generated Makefile contains

Can you check whether configure.ac overrides the value of $CC after
AM_PROG_CC_C_O?  That is the bug then.

> Can I post a testcase here? It would be about 100KByte, so I
> should ask first. (Its so big, because it includes the
> configure script and the Makefile generated on Windows.)

Not my call; if you can name all autotools versions used, it should be
possible to recreate your example without all the generated files
(configure, Makefile.in, config.status, Makefile); then it should be
small.

Cheers,
Ralf


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Harald Dunkel-2]

Hi folks,

Ralf Wildenhues wrote:

> Hi Harald,
>
> * Harald Dunkel wrote on Mon, Oct 24, 2005 at 02:19:53PM CEST:
>
>>I tried the previous patch you had sent some time ago (the
>>version with 'conf$[$]'). But this didn't work for Bill's
>>cl.exe. The generated Makefile still uses -c and -o on the same
>>command line. I had verified that the new code is in configure.
>
>
> Yes, but $(CC) should be set to something like
>  CC = compile cl
>
> and the `compile' script should take care of `-o'.
>

I think I found the problem. The compile script says at the
end
        :
        if test -f "$cofile"; then
          mv "$cofile" "$ofile"
        elif test -f "${cofile}bj"; then
          mv "${cofile}bj" "$ofile"
        fi

Using Bill's compiler $cofile is set to something like

        \\somehost\somepath\main.obj

which is not understood by test.


Regards

Harri


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Stepan Kasal]

Hello,

[ let's move to automake@... ]

On Mon, Oct 24, 2005 at 04:20:44PM +0200, Harald Dunkel wrote:

> I think I found the problem. The compile script says at the
> end
> :
> if test -f "$cofile"; then
>  mv "$cofile" "$ofile"
> elif test -f "${cofile}bj"; then
>  mv "${cofile}bj" "$ofile"
> fi
>
> Using Bill's compiler $cofile is set to something like
>
> \\somehost\somepath\main.obj
>
> which is not understood by test.

I looked at /usr/share/automake-1.9/compile and I cannot understand
how this could happen.
I think that the parametr to compile should look like
        some/path/main.c
which becomes cfile, and then cofile is assigned as

cofile=`echo "$cfile" | sed -e 's|^.*/||' -e 's/\.c$/.o/'`

But something must be different in your setup.

Happy debugging,
        Stepan


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Keith MARSHALL]

Stepan Kasal wrote:
> I think that the parametr to compile should look like
>                some/path/main.c
> which becomes cfile, and then cofile is assigned as...

Just guessing, but with cl.exe being Bill's C compiler, it
probably doesn't understand `some/path/main.c' as a path name;
(it will try to interpret the `/s' as option precursors, much
 as CP/M used to).  So the OP has forced the parameter passed
to cfile in the Win32 native `some\path\main.c' format, because
that is what cl.exe *requires*.

Regards,
Keith.


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Harald Dunkel-2]

Hi Stepan,

Stepan Kasal wrote:
>
> I looked at /usr/share/automake-1.9/compile and I cannot understand
> how this could happen.
> I think that the parametr to compile should look like
> some/path/main.c
> which becomes cfile, and then cofile is assigned as
>
> cofile=`echo "$cfile" | sed -e 's|^.*/||' -e 's/\.c$/.o/'`
>

Please check depend2.am. For the Windows compiler it
uses $(CYGPATH_W) to convert the source file pathname
even before 'compile ${CC}' is run. Currently I am looking
into the Windows part of the VPATH patch, so I had sent you
a strange compiler command line including the VPATH patch
of yesterday. But $(CYGPATH_W) is used by the unmodified
depend2.am, too.


Regards

Harri

[Paul Eggert]

Stepan Kasal <kasal@...> writes:

> A question: is there any reason to use  rm -f conftst2.*
> instead of  rm -f conftst2.$ac_objext
> Is there any C, Fortran, or F77 compiler which could create other
> conftst2.* files if it receives  -o conftst2.$ac_objext ?

Quite possibly, yes.

But why not name these files "conftest2.c" etc?  Then the
already-existing "rm -f conftest*" will clean them up.  We don't need
to worry about 8.3 file systems any more, on development platforms
anyway.


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Stepan Kasal]

Hello,

On Mon, Oct 24, 2005 at 01:41:27PM -0700, Paul Eggert wrote:
> > Is there any C, Fortran, or F77 compiler which could create other
> > conftst2.* files if it receives  -o conftst2.$ac_objext ?
>
> Quite possibly, yes.

OK, so I committed the patch attached below.

> But why not name these files "conftest2.c" etc? [...] We don't need
> to worry about 8.3 file systems any more, on development platforms
> anyway.

I know about 3 different Woe32 environments (though I don't use any):
1) Cygwin
2) MinGW
3) MinGW + MSYS

1) Cygwin doesn't have the 8.3 limitation.
2) MinGW proper doesn't have any POSIX shell, so it cannot run configure.

3) There is an MSYS build of bash.  Though MinGW/MSYS is not ready
to run Autoconf, you can use it to unpack a tarball and run ./configure
there.
Is it possible that ./configure will then run in the 8.3 environment?
I don't know and that is why I am not ready to drop the 8.3 support from
generated ./configure.

Have a nice day,
        Stepan Kasal

2005-10-25  Stepan Kasal  <kasal@...>

        * lib/autoconf/c.m4 (AC_PROG_CC_C_O): rm -f conftst2.*, not only
        conftst2.$ac_objext.
        * lib/autoconf/fortran.m4 (_AC_PROG_FC_C_O): Likewise.

Index: lib/autoconf/c.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/c.m4,v
retrieving revision 1.205
diff -u -r1.205 c.m4
--- lib/autoconf/c.m4 24 Oct 2005 10:56:01 -0000 1.205
+++ lib/autoconf/c.m4 25 Oct 2005 07:43:18 -0000
@@ -577,12 +577,12 @@
 AC_CACHE_VAL(ac_cv_prog_cc_${ac_cc}_c_o,
 [AC_LANG_CONFTEST([AC_LANG_PROGRAM([])])
 ac_clean_files_save=$ac_clean_files
-ac_clean_files="$ac_clean_files conftst2.$ac_objext"
+ac_clean_files="$ac_clean_files conftst2.*"
 # Make sure it works both with $CC and with simple cc.
 # We do the test twice because some compilers refuse to overwrite an
 # existing .o file with -o, though they will create one.
 ac_try='$CC -c conftest.$ac_ext -o conftst2.$ac_objext >&AS_MESSAGE_LOG_FD'
-rm -f conftst2.$ac_objext
+rm -f conftst2.*
 if AC_TRY_EVAL(ac_try) &&
    test -f conftst2.$ac_objext && AC_TRY_EVAL(ac_try);
 then
@@ -591,7 +591,7 @@
     # Test first that cc exists at all.
     if AC_TRY_COMMAND(cc -c conftest.$ac_ext >&AS_MESSAGE_LOG_FD); then
       ac_try='cc -c conftest.$ac_ext -o conftst2.$ac_objext >&AS_MESSAGE_LOG_FD'
-      rm -f conftst2.$ac_objext
+      rm -f conftst2.*
       if AC_TRY_EVAL(ac_try) &&
  test -f conftst2.$ac_objext && AC_TRY_EVAL(ac_try);
       then
@@ -606,7 +606,7 @@
 else
   eval ac_cv_prog_cc_${ac_cc}_c_o=no
 fi
-rm -f conftest* conftst2.$ac_objext
+rm -f conftest* conftst2.*
 ac_clean_files=$ac_clean_files_save
 ])dnl
 if eval "test \"`echo '$ac_cv_prog_cc_'${ac_cc}_c_o`\" = yes"; then
Index: lib/autoconf/fortran.m4
===================================================================
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/fortran.m4,v
retrieving revision 1.196
diff -u -r1.196 fortran.m4
--- lib/autoconf/fortran.m4 24 Oct 2005 10:56:02 -0000 1.196
+++ lib/autoconf/fortran.m4 25 Oct 2005 07:43:18 -0000
@@ -460,11 +460,11 @@
                [ac_cv_prog_[]_AC_LANG_ABBREV[]_c_o],
 [AC_LANG_CONFTEST([AC_LANG_PROGRAM([])])
 ac_clean_files_save=$ac_clean_files
-ac_clean_files="$ac_clean_files conftst2.$ac_objext"
+ac_clean_files="$ac_clean_files conftst2.*"
 # We test twice because some compilers refuse to overwrite an existing
 # `.o' file with `-o', although they will create one.
 ac_try='$[]_AC_FC[] $[]_AC_LANG_PREFIX[]FLAGS -c conftest.$ac_ext -o conftst2.$ac_objext >&AS_MESSAGE_LOG_FD'
-rm -f conftst2.$ac_objext
+rm -f conftst2.*
 if AC_TRY_EVAL(ac_try) &&
      test -f conftst2.$ac_objext &&
      AC_TRY_EVAL(ac_try); then
@@ -472,7 +472,7 @@
 else
   ac_cv_prog_[]_AC_LANG_ABBREV[]_c_o=no
 fi
-rm -f conftest* conftst2.$ac_objext
+rm -f conftest* conftst2.*
 ac_clean_files=$ac_clean_files_save
 ])
 if test $ac_cv_prog_[]_AC_LANG_ABBREV[]_c_o = no; then

[Keith MARSHALL]

Stepan Kasal wrote:
> 3) There is an MSYS build of bash.  Though MinGW/MSYS is not ready
> to run Autoconf, you can use it to unpack a tarball and run ./configure
> there.

I don't know where you get this idea from.  I have been using Autoconf
2.59 in the MSYS environment for at least nine months now, and prior
to that, Autoconf 2.56 for at least the past two years.

> Is it possible that ./configure will then run in the 8.3 environment?
> I don't know and that is why I am not ready to drop the 8.3 support from
> generated ./configure.

Microsoft added long file name support in Win95 -- the first of the 32-bit
Windoze releases.  The requirement to support 8.3 file names disappeared
with the demise of MS-DOS, around the same time.

To clarify:  MinGW is a port of GCC, to run natively on Win32;  MSYS is
a minimal POSIX-like tool suite, also running natively on Win32, and
*specifically* intended to facilitate the use of GNU development tools.
When coupled together, these provide a convenient environment for the
development of Win32 ports of GNU, and GNU-like, applications.  The
ability to use Autoconf is a fundamental requirement in this environment,
and it is certainly well supported.

Best regards,
Keith.


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Stepan Kasal]

Hello,

[ ccing Eli, a DOS expert ]

On Tue, Oct 25, 2005 at 12:47:10PM +0100, Keith MARSHALL wrote:
> Stepan Kasal wrote:
> > 3) There is an MSYS build of bash.  Though MinGW/MSYS is not ready
> > to run Autoconf, you can use it to unpack a tarball and run ./configure
> > there.
>
> I don't know where you get this idea from.  I have been using Autoconf
> 2.59 in the MSYS environment for at least nine months now, and prior
> to that, Autoconf 2.56 for at least the past two years.

I don't know either.  :-)
Thank you for your explanation.

> Microsoft added long file name support in Win95 -- the first of the 32-bit
> Windoze releases.  The requirement to support 8.3 file names disappeared
> with the demise of MS-DOS, around the same time.

OK.  So there is one more question:
Eli: is there any need for ./configure to be compatible with 8.3 filesystems?

Have a nice day,
        Stepan Kasal


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf