Greg Pettyjohn
2006-May-07 18:46 UTC
[LLVMdev] Configuring for the cfrontend build on Mingw
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?