[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cfe-dev
Subject:    Re: [cfe-dev] Header Search Paths with MinGW
From:       Sandeep Patel <deeppatel1987 () gmail ! com>
Date:       2010-08-31 20:40:10
Message-ID: AANLkTik+GGNJ3vtiocqA0TeTj9M9ybAjb1ugoGomwRsz () mail ! gmail ! com
[Download RAW message or body]

This only works if the build == host.

I routinely build with build = darwin, host = mingw. I don't use CMake either.

If you can improve the search paths, that would be great, but please
bear in mind that your build approach isn't the only one.

deep

On Tue, Aug 31, 2010 at 1:50 PM, Fernando Pelliccioni
<fpelliccioni@gmail.com> wrote:
> Hi,
>
> I found a problem and I am writing to propose a solution, I would like to
> know what you think.
> I am working on Win32 with MinGW (GCC 4.4)
>
> I quote an extract of the InitHeaderSearch class (
> /tools/clang/lib/Frontend/InitHeaderSearch.cpp )
>
> //----------------------------------------------------------------------------------------------------
>
> void InitHeaderSearch::AddMinGWCPlusPlusIncludePaths(llvm::StringRef Base,
>                                                      llvm::StringRef Arch,
>                                                      llvm::StringRef
> Version) {
>
>   AddPath(Base + "/" + Arch + "/" + Version + "/include",
>           System, true, false, false);
>   AddPath(Base + "/" + Arch + "/" + Version + "/include/c++",
>           System, true, false, false);
>   AddPath(Base + "/" + Arch + "/" + Version + "/include/c++/backward",
>           System, true, false, false);
> }
>
> void InitHeaderSearch::AddDefaultCPlusPlusIncludePaths(const llvm::Triple
> &triple) {
> //...
>   case llvm::Triple::MinGW64:
>     // Try gcc 4.4.0
>     AddMinGWCPlusPlusIncludePaths("c:/MinGW/lib/gcc", "mingw64", "4.4.0");
>     // Try gcc 4.3.0
>     AddMinGWCPlusPlusIncludePaths("c:/MinGW/lib/gcc", "mingw64", "4.3.0");
>     // Fall through.
>   case llvm::Triple::MinGW32:
>     // Try gcc 4.4.0
>     AddMinGWCPlusPlusIncludePaths("c:/MinGW/lib/gcc", "mingw32", "4.4.0");
>     // Try gcc 4.3.0
>     AddMinGWCPlusPlusIncludePaths("c:/MinGW/lib/gcc", "mingw32", "4.3.0");
>     break;
> //...
> }
>
> //----------------------------------------------------------------------------------------------------
>
> For example, in this line ...
>
>     AddMinGWCPlusPlusIncludePaths("c:/MinGW/lib/gcc", "mingw32", "4.4.0");
>
> ... "mingw32" corresponds to the parameter "Arch" of function
> "AddMinGWCPlusPlusIncludePaths". It is harcoded!
>
>
> In GCC, if I want to know what is the Header Seach Path, I can run ...
>
>     > g++ -v -c xxx.cpp
>
>         ...
>         #include "..." search starts here:
>         #include <...> search starts here:
>          c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++
>          c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/mingw32
>          c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include/c++/backward
>          c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include
>          c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include
>          c:\mingw\bin\../lib/gcc/mingw32/4.4.0/include-fixed
>          c:\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../mingw32/include
>         End of search list.
>         ...
>
>
> I tried another implementation of MinGW (GCC 4.6) in which I got X.
>
>          c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/include/c++
>
>  c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/include/c++/i686-pc-mingw32
>          c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/include/c++/backward
>          c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/../../../../include
>          c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/include
>          c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/include-fixed
>
>  c:\mingw\bin\../lib/gcc/i686-pc-mingw32/4.6.0/../../../../i686-pc-mingw32/include
>
>
> The problem is in the "Arch" parameter, in one implementation I have
> "mingw32" and in the other "i686-pc-mingw32"
>
> How I can know which parameter to use?
>
> The answer is...
>
>     > g++ -dumpmachine
>     mingw32
>
> or in the second MinGW implementation...
>
>     > g++ -dumpmachine
>     i686-pc-mingw32
>
>
> To fix this, I propose to add a new preprocessor #define on "config.h" and
> "llvm-config.h", like the following...
>
>     #define LLVM_MINGW_DUMPMACHINE "mingw32"
>
> LLVM_MINGW_DUMPMACHINE is fed in the CMake configuration phase, and can be
> used in the InitHeaderSearch class as follows...
>
>     AddMinGWCPlusPlusIncludePaths("c:/MinGW/lib/gcc",
> llvm::StringRef(LLVM_MINGW_DUMPMACHINE), "4.4.0");
>
>
> The files involved are:
>
> /cmake/config-ix.cmake
> /cmake/modules/GetTargetTriple.cmake
> /include/llvm/Config/config.h.cmake
> /include/llvm/Config/llvm-config.h.cmake
> /include/llvm/Config/config.h.in
> /include/llvm/Config/llvm-config.h.in
> /tools/clang/lib/Frontend/InitHeaderSearch.cpp
>
>
>
> I want to know what do you think about this solution. If you approve, I will
> send the patches.
>
> The next step is to avoid the hardcoding of "c:/MinGW/lib/gcc"...
>
>
> Thanks and Regards.
> Fernando Pelliccioni.
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>

_______________________________________________
cfe-dev mailing list
cfe-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

[prev in list] [next in list] [prev in thread] [next in thread]