Re: [Mingw-msys] [Mingw-users] error when using autoconf 2.60 or 2.61 with MSYS/MinGW

[Keith M. <kei...@to...>]

Continuing a discussion originating on MinGW-Users:
http://thread.gmane.org/gmane.comp.gnu.mingw.user/22580

Vincent Torri wrote:
> I use MSYS-1.0.11 CORE (from snapshot)...
>
> I've installed MSYS DTK 1.0.1
>
> I've just installed autoconf 2.61 in /usr/local. I get the same
> error. For example, when compiling automake 1.10:
>
> checking whether autoconf is installed... yes
> checking whether autoconf works... no
>
> the config.log file reports:
>
> configure:2310: checking whether autoconf is installed
> configure:2315: eval autoconf --version
> autoconf (GNU Autoconf) 2.61
> Copyright (C) 2006 Free Software Foundation, Inc.
> ...
> configure:2318: $? = 0
> configure:2326: result: yes
> configure:2336: checking whether autoconf works
> configure:2343: cd conftest && eval autoconf -o /dev/null conftest.ac
> /usr/local/bin/autoconf: 
> /home/vincent/automake-1.10/conftest/D:/msys/1.0/local/bin/autom4te:
>  No such file or directory
> /usr/local/bin/autoconf: exec: 
> /home/vincent/automake-1.10/conftest/D:/msys/1.0/local/bin/autom4te: 
>  cannot execute: No such file or directory
> configure:2346: $? = 126
> configure:2355: result: no
>
> If I just run autoconf in a lib I want to compile:
>
> /usr/local/bin/autoconf: 
> /home/vincent/libdvi/D:/msys/1.0/local/bin/autom4te:
>  No such file or directory
> /usr/local/bin/autoconf: exec: 
> /home/vincent/libdvi/D:/msys/1.0/local/bin/autom4te:
>  cannot execute: No such file or directory

I certainly cannot reproduce this; I just did

  $ cd tmp

  $ pwd
  /home/keith/tmp

  $ file `which autoconf`
  /usr/local/bin/autoconf: Bourne shell script text executable

  $ file `which autom4te`
  /usr/local/bin/autom4te: perl script text executable

  $ file `which perl`
  /bin/perl.exe: PE executable for MS Windows (console) Intel 80386

  $ perl --version

  This is perl, v5.6.1 built for msys

  Copyright 1987-2001, Larry Wall
  ...

  $ autoconf --version
  autoconf (GNU Autoconf) 2.61
  Copyright (C) 2006 Free Software Foundation, Inc.
  ...

  $ echo AC_INIT > configure.ac

  $ autoconf

  $ ls
  autom4te.cache  configure  configure.ac

Note that this exactly as I would expect, indicating normal operation.
If I explicitly move autom4te out of the way...

  $ (cd `dirname \`which autom4te\`` && mv autom4te autom8)

  $ autoconf
  /usr/local/bin/autoconf: line 582: /usr/local/bin/autom4te:
   No such file or directory
  /usr/local/bin/autoconf: line 582: exec: /usr/local/bin/autom4te:
   cannot execute: No such file or directory

  $ (cd `dirname \`which autom8\`` && mv autom8 autom4te)

...then autoconf does fail, as expected, but I still see the POSIX
style path names in the error messages.

> Note that autoconf 2.59 has no problem.

This is even more mysterious.  It appears that you have identified a
possible cause...

> Cesar Strauss wrote:
>> How did you invoke the configure script?
>>
>> I saw this problem in the past, when I used DOS paths in the configure
>> line (--prefix=`cd /mingw && pwd -W`). A solution was to use the POSIX
>> path (--prefix=/mingw). I believe this is because autoconf is
>> interpreted by perl, which is a MSYS application, and has POSIX
>> semantics.
>
> I think that I have found the problem. I have not mentioned that I used
> a mingw port made my myself (with portmaker), and the configure script
> is called like that :
>
> CONFIGURE_OPTIONS=${CONFIGURE_OPTIONS-"--prefix='`win32path 
${PREFIX}`'"}
>
> So it is certainly the problem.

It certainly seems plausible;  however, when I originally built autoconf
2.60, I had

  ac_default_prefix=`cd /usr/local && pwd -W`

in my config.site file.  This would have identically the same effect as
that `CONFIGURE_OPTIONS` setting, (`win32path is a function, which if
PREFIX is set to /usr/local, effectively expands to that same command).

> when I compile from source, there is no problem.

...this would seem to confirm the hypothesis, that this is indeed the
problem.

> sorry for having bothering you

No bother, and the discussion has certainly been useful; no need to
apologise.

> and having not mentioned that i was using a mingw port.

Well, we all dismiss some things as unlikely to be relevant, until
enlightenment dawns.  Note how I've formulated that CONFIGURE_OPTIONS
setting; it will only take effect if CONFIGURE_OPTIONS has not been
previously assigned a value.  For your mingwPORT, you could add

  CONFIGURE_OPTIONS='--prefix=${PREFIX}'

to mingwPORT.ini, (note the single quotes), to preserve the POSIX
style path for the PREFIX assignment in configure.  (If that doesn't
work, I want to know, please, because this is a feature of mingwPORT
which I'm still developing).

Regards,
Keith.