[multilib] Teach Clang's code about multilib by threading
authorChandler Carruth <chandlerc@gmail.com>
Mon, 29 Dec 2014 12:09:08 +0000 (12:09 +0000)
committerChandler Carruth <chandlerc@gmail.com>
Mon, 29 Dec 2014 12:09:08 +0000 (12:09 +0000)
commitfd3cc70ed46b3cca63f539a5118340547d55fc8b
tree2b0b2f175755032dd71e1fe2ccba597cc645fc75
parent91663e55f651bebf99afc97d9b7a1958f5e9e9fa
[multilib] Teach Clang's code about multilib by threading
a CLANG_LIBDIR_SUFFIX down from the build system and using that as part
of the default resource dir computation.

Without this, essentially nothing that uses the clang driver works when
building clang with a libdir suffix. This is probably the single biggest
missing piece of support for multilib as without this people could hack
clang to end up installed in the correct location, but it would then
fail to find its own basic resources. I know of at least one distro that
has some variation on this patch to hack around this; hopefully they'll
be able to use the libdir suffix functionality directly as the rest of
these bits land.

This required fixing a copy of the code to compute Clang's resource
directory that is buried inside of the frontend (!!!). It had bitrotted
significantly relative to the driver code. I've made it essentially
a clone of the driver code in order to keep tests (which use cc1
heavily) passing. This copy should probably just be removed and the
frontend taught to always rely on an explicit resource directory from
the driver, but that is a much more invasive change for another day.

I've also updated one test which actually encoded the resource directory
in its checked output to tolerate multilib suffixes.

Note that this relies on a prior LLVM commit to add a stub to the
autoconf build system for this variable.

llvm-svn: 224924
clang/CMakeLists.txt
clang/include/clang/Config/config.h.cmake
clang/include/clang/Config/config.h.in
clang/lib/Driver/Driver.cpp
clang/lib/Frontend/CompilerInvocation.cpp
clang/test/Preprocessor/iwithprefix.c