Re: AC_CYGWIN etc. (Was: AC_OBJEXT again)

[Mo DeJong]

> Here is my proposal.
> 
> 
> Index: ChangeLog
> from  Akim Demaille  <address@hidden>
>       Put back AC_CYGWIN etc. under the responsibility of the
>       configure.in maintainer, but discourage its use.
> 
>       * acspecific.m4 (_AC_CYGWIN, _AC_MINGW32, _AC_EMXOS2): Rename as...
>       (AC_CYGWIN, AC_MINGW32, AC_EMXOS2): these.
>       AU defined on top of AC_CANONICAL_HOST and $host_os.
>       * tests/mktests.sh (update_exclude_list): Add AC_CYGWIN,
>       AC_MINGW32, and AC_EMXOS2.


Here is something I do not quite get, I was under the
impression that AC_CYGWIN, AC_MINGW32, and the like
were being run when AC_PROG_CC was run. This new patch
does not seem to run them anymore.


I did a little testing with this patch.

...
checking build system type... i686-pc-linux-gnu
checking host system type... i386-pc-mingw32msvc
checking for i386-mingw32msvc-g++... i386-mingw32msvc-g++
checking whether the C++ compiler works... yes
checking whether we are cross compiling... yes
checking whether we are using the GNU C++ compiler... yes
checking for object suffix... o
checking for executable suffix... 
checking whether i386-mingw32msvc-g++ accepts -g... yes

Strange part is, my cross compiler is not writing out
a .exe file, so the system thinks that the EXEEXT
is "".

% ./i386-mingw32msvc-gcc -o run tmp.c

% ls -la run*
-rwxrwxr-x    1 mo       mo          14581 Dec 13 18:26 run

% file run
run: MS Windows PE 32-bit Intel 80386 console executable not relocatable

I am at a loss to explain that one. I would think that a
Linux cross mingw compiler would need to output a .exe
file, but it does not.

Mo DeJong
Red Hat Inc