By checking http://wiki.openttd.org/Compiling_on_Windows_using_MinGW,

I realized that you should first start your msys.bat at ${MinGW_PATH}\msys\1.0\msys.bat( mine is C:\MinGW\msys\1.0\msys.bat ).

There you can then do whatever you likes to do.

./configure
make
make install
...

If a software project is set up to be built using autoconf, that tool generates a script canonically called configure. It queries the system for various parameters that are subsequently used in the build, and is specific to the software package to be built. Different software projects have different configure scripts. They are all called configure, but their contents are not the same.

So, to actually build such a software project once that script was set up (usually done by the maintainers when packaging the source tarball for distribution), you call:

tar xzf <tarball>.gz   # or xjf <tarball>.bz2 or whatever
cd <sourcedir>         # the one you just untarred
./configure
make
make install

Note the prefix ./, which means "located in this directory" (i.e. the top directory of that project's source tree).

Actually, the better procedure is the so-called "out-of-tree build", when you set up a different directory for the binaries to be built in, so the source tree remains unmodified:

tar xzf <tarball>.gz     # or xjf <tarball>.bz2 or whatever
mkdir builddir
cd builddir
../<sourcedir>/configure
make
make install

So, there is supposed to be no configure executable in your PATH, you are supposed to call the script of that name from the source tree you are trying to build from.

Usually 'you do not run configure'.

If the source code you try to compile has those instructions, you might be lucky with some mingw build environment (e.g. msys or something more modern). Sometimes it works with Cygwin or inside Interix, but often it just adds to the troubles.

But if the README etc. does not mention Windows, you will probably not get very far that way, as usually some headers or libraries will be missing etc. A configure script is just a unix shell script, so it might call all kinds of unix tools or use unix shell features. Only a very limited set of those tools work on Windows, or make sense on windows.

So, it all depends on what you really want to build. For a lot of things there are portable buildsystems like CMake or special build instructions for Windows.

As you now mentioned, you want to compile CLANG, you surely do not want to use the configure step. See the clang/llvm documentation or the link mentioned by @Fruch (How to compile Clang on Windows) in the comments.

If the file is called configure.ac,

do $> autoconf

Depends: M4, Automake

If you're not sure what to do,

try $> cat readme

They must mean that you use "autoconf" to generate an executable "configure" file.

So the order is:

$> autoconf
$> ./configure
$> make
$> make install

All those error messages are generated by the shell code in configure which AC_OUTPUT expands to.

There is nothing you can get wrong about writing AC_OUTPUT on a line by itself, so there is something wrong in the macros which happen before AC_OUTPUT and which set up things for AC_OUTPUT, both in the sh and in the m4 realm.

As a general remark, the configure.ac uses an uncommon sequence of events, and is a bit weird in other ways as well.

The specific weirdness which breaks things for you turns out to be the multiple lines in configure.ac which contain LT_INIT, some of which have the win32-dll argument some do not: The LT_INIT macro is only expanded into shell code the first time it appears in configure.ac and all subsequent LT_INIT macro invocations are substituted by no shell code at all.

So unless the first LT_INIT in the first case branch runs, no libtool related shell variables will be set, and the libtool shell code produced by AC_OUTPUT which relies on those variables will fail.

The fix on your side is easy: Just put one LT_INIT([win32-dll]) inside configure.ac, outside of all if or case conditionals.

On libtool's side, they could have LT_INIT produce an autoreconf time error message instead of expanding LT_INIT to an empty string, but that does not help you right now.

Here is OP's github issue for this question, and my github pull request with a fix.

How did I find this?

• I put a bunch of echo AAAAAAAAAAAAAA and echo BBBBBBBBBBB lines into multiple places in configure.ac. The problem happened after the line which I put just before AC_OUTPUT and before the line which I put after AC_OUTPUT.

• I restored configure.ac using git and I commented out AC_OUTPUT by adding dnl at the beginning of the AC_OUTPUT line. That confirmed the location where the problem occurred.

• I restored configure.ac using git and commented out just about everything after AC_CANONICAL_HOST and before AC_OUTPUT with the exception of the AM_CONDITIONAL lines. This got rid of the problem.

• I then successively uncommented those lines in logically cohesive chunks of a few dozen lines until the problem reappeared. The problem reappeared once I uncommented the case $build in ... esac which deals with defining some variables like SHAREDEXT and SHARED_LDFLAGS and SEP and WIN32, AC_DEFINEs the WIN32 macro, and expands the LT_INIT macro.

• I restored configure.ac using git and commented out all the LT_INIT lines, putting just one LT_INIT([win32-dll]) line just before the above mentioned case $build in ... esac to reconfirm.

• I checked m4/libtool.m4 and looked for the implementation of LT_INIT. As it turns out, when m4 expands LT_INIT for the first time, it redefines the LT_INIT macro to expand to nothing.

configure is normally a (generated) shell script which is packaged in Unix-based applications and is used to detect certain machine settings and set up needed files for make to do its job.

Look for a configure.bat or a file called configure in the QT directory and run it.