MinGW header search paths (InitHeaderSearch.cpp)

I noticed a big blob of ugly code in InitHeaderSearch.cpp, especially when MinGW is involved. Aside from its atrocity, it assumes that MinGW is installed in c:…, which is not true for my system (and may not be true for others as well).

I would propose to change this hackery to a single (set of) path(s) deduced from the location of the gcc executable used to link the Clang generated object files together.

Two things are required for this to work:

  1. Clang needs to be able to locate the gcc executable (from PATH), including version and target info (for step 2)
  2. Relative paths need to be generated from that location.

Is this a sensible way of solving the problem?

Ruben

Perhaps. This is a longstanding issue across platforms; probing GCC at ./configure time to find the paths it uses would probably be most effective.

  - Doug

2011/4/22 Douglas Gregor <dgregor@apple.com>

Having Clang call GCC every time it is invoked seems like an unacceptable performance penalty to me.

  • Doug

I didn't interpret his suggestion that way, I thought it was more
along the lines of doing what the 'which gcc' command does.

Reid

I didn't interpret his suggestion that way, I thought it was more
along the lines of doing what the 'which gcc' command does.

Ah, my mistake. We could try that for mingw at least. In general, it doesn't work as well as actually invoking GCC, since every build of GCC seems to like to put its standard library in a different place.

  - Doug

2011/4/22 Douglas Gregor <dgregor@apple.com>

I didn’t interpret his suggestion that way, I thought it was more
along the lines of doing what the ‘which gcc’ command does.

Ah, my mistake. We could try that for mingw at least. In general, it doesn’t work as well as actually invoking GCC, since every build of GCC seems to like to put its standard library in a different place.

That was indeed my plan. We can perhaps read the /…/include/c++/ subfolders with random/all versions/targets and add them to the search directories. Once libcxx works with mingw and on windows in general, we can get rid of this foolishness and just add the <clang(++)location>/…/include(/c++) and be done with it (for Windows at least).

Does Clang have any functions to read files/directories or is that a task for the Win32 API?

Ruben

> I didn't interpret his suggestion that way, I thought it was more
> along the lines of doing what the 'which gcc' command does.

Ah, my mistake. We could try that for mingw at least. In general, it doesn't work as well as actually invoking GCC, since every build of GCC seems to like to put its standard library in a different place.

That was indeed my plan. We can perhaps read the <gcclocation>/../include/c++/ subfolders with random/all versions/targets and add them to the search directories. Once libcxx works with mingw and on windows in general, we can get rid of this foolishness and just add the <clang(++)location>/../include(/c++) and be done with it (for Windows at least).

This still sounds pretty ugly. I'd be more for a configure time and a flag at runtime if you want to override it.

Does Clang have any functions to read files/directories or is that a task for the Win32 API?

llvm has some. Look in llvm/lib/Support

-eric

On gentoo x86_64, the libstc++ headers are in
<gcclocation>/../lib64/<triple>/<gcc-version>/include/g++-v4
and
<gcclocation>/../lib64/<triple>/<gcc-version>/include/g++-v4/<triple>
so things aren't so simple.

  Tom

Right. This is actually an extremely hard problem to solve well. Ideally, we'd have ./configure map out the libraries that could be used, and pick a default one that works for the system.

  - Doug

Douglas Gregor <dgregor@apple.com> writes:

Having Clang call GCC every time it is invoked seems like an
unacceptable performance penalty to me.

So call it only once and cache the results on some configuration file.

2011/4/22 Douglas Gregor <dgregor@apple.com>

I didn’t interpret his suggestion that way, I thought it was more
along the lines of doing what the ‘which gcc’ command does.

Ah, my mistake. We could try that for mingw at least. In general, it
doesn’t work as well as actually invoking GCC, since every build of GCC
seems to like to put its standard library in a different place.

That was indeed my plan. We can perhaps read the
/…/include/c++/ subfolders with random/all versions/targets
and add them to the search directories. Once libcxx works with mingw and on
windows in general, we can get rid of this foolishness and just add the
<clang(++)location>/…/include(/c++) and be done with it (for Windows at
least).

On gentoo x86_64, the libstc++ headers are in
/…/lib64///include/g+±v4
and
/…/lib64///include/g+±v4/
so things aren’t so simple.

Right. This is actually an extremely hard problem to solve well. Ideally, we’d have ./configure map out the libraries that could be used, and pick a default one that works for the system.

This is a perfectly good way on Linux, where every distro keeps its own packages. But there is no way one can distribute a standalone clang on Windows (and allow the user to use his MinGW installation). I’m trying to get a way to download a LLVM/clang binary package for use with “your” MinGW. Linux generally does not have this diversity; mostly, people use system GCC, on Windows, it might come with your IDE, from mingw.org, from TDM-GCC, some Russian site, etc. And they’re all equally valid.

Ruben

I'd rather think lang should have its own libraries and should be
freestanding from GNU toolchain as possible.

For now, for mingw, I suggest two ways;

  1. Support sysroot, by default, "c:/mingw" is assumed.
  2. Add default sysroot as "${clang.exe's dir}/.. , when clang.exe is
installed to ${your_mingw_distro}/bin.

In future, I suggest;

  0. Get rid of gcc.exe driver for linking. Use ld.exe directly.
  1. Provide our mingw. distributed llvm-gcc does.
  2. Provide our compiler_rt and libcxx for mingw.
  3. Provide our linker.

...Takumi