[LLVMdev] Configuring for the cfrontend build on Mingw

Greg Pettyjohn
Sun, 07 May 2006 18:46:34 -0000

So the fundamental problem I'm trying to solve is how get my cfrontend
build configured properly.

The usual symptom of an incorrect configuration is the inability to find
various header files.

Here's some example spew:

$ /home/llvm_home/llvm-gcc-build/gcc/xgcc -v
-B/home/llvm_home/llvm-gcc-build/gcc/ -Bc:/msys/1.0/mingw32/bin/
-Bc:/msys/1.0/mingw32/lib/ -isystem c:/msys/1.0/mingw32/include -isystem
c:/msys/1.0/mingw32/sys-include -O2
-I../../llvm-gcc/gcc/../winsup/w32api/include -DIN_GCC -DCROSS_COMPILE
-DDEFAULT_TARGET_MACHINE=\"mingw32\"   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -isystem ./include   -g
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I -I
-I../../llvm-gcc/gcc -I../../llvm-gcc/gcc/ -I../../llvm-gcc/gcc/../include
-DL_muldi3 -c ../../llvm-gcc/gcc/libgcc2.c -o libgcc/./_muldi3.o
 Reading
specs from C:/msys/1.0/home/llvm_home/llvm-gcc-build/gcc/specs
Configured with: ../llvm-gcc/configure --target=mingw32
--prefix=/home/llvm_home/install --disable-threads --disable-nl
s --disable-shared --enable-languages=c,c++ --disable-c-mbchar
--program-prefix=llvm- --exec-prefix=c:/msys/1.0
Thread model: single
gcc version 3.4-llvm 20051104 (LLVM 1.7cvs)
 C:/msys/1.0/home/llvm_home/llvm-gcc-build/gcc/cc1.exe -quiet -v
-I../../llvm-gcc/gcc/../winsup/w32api/include -I. -I -
I -I../../llvm-gcc/gcc -I../../llvm-gcc/gcc/
-I../../llvm-gcc/gcc/../include -iprefix C:\msys\1.0\home\llvm_home\llvm-g
cc-build\gcc\../lib/gcc/mingw32/3.4-llvm/ -isystem
C:/msys/1.0/home/llvm_home/llvm-gcc-build/gcc/include -isystem c:/ms
ys/1.0/mingw32/bin/include -isystem c:/msys/1.0/mingw32/lib/include
-DIN_GCC -DCROSS_COMPILE -DDEFAULT_TARGET_MACHINE="
mingw32" -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -DL_muldi3
-isystem c:/msys/1.0/mingw32/include -isystem
c:/msys/1.0/mingw32/sys-include -isystem ./include
../../llvm-gcc/gcc/libgcc2.c -quiet -dumpbase libgcc2.c -auxbase-str
ip libgcc/./_muldi3.o -g -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -version -o C:/DOCUME~1/
GREGPE~1/LOCALS~1/Temp/cca0aaaa.s
ignoring nonexistent directory "c:/msys/1.0/mingw32/bin/include"
ignoring nonexistent directory "c:/msys/1.0/mingw32/lib/include"
ignoring nonexistent directory "c:/msys/1.0/mingw32/include"
ignoring nonexistent directory "c:/msys/1.0/mingw32/sys-include"
ignoring nonexistent directory
"C:\msys\1.0\home\llvm_home\llvm-gcc-build\gcc\../lib/gcc/mingw32/3.4-llvm/include"
ignoring nonexistent directory
"C:\msys\1.0\home\llvm_home\llvm-gcc-build\gcc\../lib/gcc/mingw32/3.4-llvm/../../../../.
./../mingw32/sys-include"
ignoring nonexistent directory
"C:\msys\1.0\home\llvm_home\llvm-gcc-build\gcc\../lib/gcc/mingw32/3.4-llvm/../../../../.
./../mingw32/include"
ignoring nonexistent directory
"c:/msys/1.0/lib/gcc/mingw32/3.4-llvm/include"
ignoring nonexistent directory
"c:/msys/1.0/lib/../../../mingw32/sys-include"
ignoring nonexistent directory
"c:/msys/1.0/lib/../../../mingw32/include"
ignoring nonexistent directory
"../../llvm-gcc/gcc/../winsup/w32api/include"
ignoring nonexistent directory "-I"
ignoring nonexistent directory "../../llvm-gcc/gcc/"
#include "..." search starts here:
#include <...> search starts here:
 .
 ../../llvm-gcc/gcc
 ../../llvm-gcc/gcc/../include
 C:/msys/1.0/home/llvm_home/llvm-gcc-build/gcc/include
 ./include
End of search list.
GNU C version 3.4-llvm 20051104 (LLVM 1.7cvs) (mingw32)
        compiled by GNU C version 3.4.2 (mingw-special).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
In file included from ../../llvm-gcc/gcc/config/i386/i386.h:37,
                 from ./tm.h:4,
                 from ../../llvm-gcc/gcc/libgcc2.c:43:
../../llvm-gcc/gcc/llvm-out.h:30:19: stdio.h: No such file or directory
In file included from ../../llvm-gcc/gcc/config/i386/i386.h:37,
                 from ./tm.h:4,
                 from ../../llvm-gcc/gcc/libgcc2.c:43:
../../llvm-gcc/gcc/llvm-out.h:69: error: syntax error before '*' token
../../llvm-gcc/gcc/llvm-out.h:69: warning: function declaration isn't a
prototype
In file included from ./tm.h:9,
                 from ../../llvm-gcc/gcc/libgcc2.c:43:
../../llvm-gcc/gcc/config/i386/cygming.h:330: error: syntax error before
'*' token
../../llvm-gcc/gcc/config/i386/cygming.h:330: warning: function
declaration isn't a prototype


Through experimentation, running the debugger, digging through Makefiles,
configure scripts, etc. I've made the following observations:

1. The "ignoring nonexistent directory ..." messages can be enabled
via
the -v flag. They originate from within c-incpath.c. A directory will be
ignored if it gets rejected by fstat().

2. fstat() rejects paths that end with a slash (or backslash). In the
above example, observe:

  ignoring nonexistent directory "../../llvm-gcc/gcc/"

while: "../../llvm-gcc/gcc" is not "ignored".

3. One potential point of control is the INCLUDES variable found in
cfrontent/gcc/Makefile.in:

INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
	   -I$(srcdir)/../include @INCINTL@

4. It is worth mentioning that there is a subtle interaction with (my
particular version of) make. In some cases make should be replacing $(@D)
with '.', but instead replaces it with '' (nothing).  You end up
with
   ... -I. -I -Isome/src/path  -I/some/src/path/ ...

then the -I -Isome/src/path is interpreted as a single '-I' with
argument
'-Isome/src/path'. To work around this, I make the following the
adjustment (hack) to INCLUDES:

INCLUDES = -I. -I$(@D) -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
	   -I$(srcdir)/../include @INCINTL@

In this case, the first degenerate -I gobbles up the one following it and
then things accidentally work.

5. At one point, I was simply adding the path to the headers to the
INCLUDES:

INCLUDES = -I. -I$(@D) -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \
	   -IC:/msys/1.0/mingw/include -I$(srcdir)/../include @INCINTL@

This got me past the first round of missing headers. However, the INCLUDES
variable doesn't seem to be passed along when the build later on
configures in libstdc++-v3

6. Another point of control are the settings for the --exec-prefix and
--target options supplied to configure.

These two values are combined to create the FLAGS_FOR_TARGET variable that
gets propagated to the later build phases:

The paths are built up as follows (see configure for details)

  FLAGS_FOR_TARGET=$FLAGS_FOR_TARGET' -B$(build_tooldir)/bin/
-B$(build_tooldir)/lib/ -isystem $(build_tooldir)/include -isystem
$(build_tooldir)/sys-include'

where:
   build_tooldir = $tooldir

and where:
   tooldir = '${exec_prefix}'/${target_alias}

and finally where:
   $target_alias = $target

7. It would seem that I might possibly solve my problem by simply
supplying the right value for --exec-prefix. The --help option to
configure yields the following description for --exec-prefix:

  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
                          [same as prefix]

This is a little vague:
Q: Will the build process actually install stuff there?
Q: Is this just where things (headers, libs) are currently installed?
Q: It doesn't really say that this is used to construct a search path,
but is that how it is intended?

rather useless help if you ask me!

8. Another plausible solution is to just not supply anything for
--exec-prefix and then copy the files (headers, libs) to the location
where the build process will look for them. I've seen this recommended on
forums for building gcc on MinGW. I've also downloaded a script from the
MinGW wiki for bootstrapping gcc, which includes this as a step.


Advice? Comments?