compiler-rt fails to build with the packages are installed on the system

Hello,

Recently, compiler-rt build started to fail when the package are also
installed on the system.

  COMPILE: clang_linux/full-x86_64/x86_64:
/tmp/buildd/llvm-toolchain-snapshot-3.4~svn193538/projects/compiler-rt/lib/addvsi3.c
/tmp/buildd/llvm-toolchain-snapshot-3.4~svn193538/build-llvm/Release+Asserts/bin/clang
-fPIC -Wall -Werror -O3 -fomit-frame-pointer -m64
--sysroot=/tmp/buildd/llvm-toolchain-snapshot-3.4~svn193538/projects/compiler-rt/SDKs/linux
-c -o
/tmp/buildd/llvm-toolchain-snapshot-3.4~svn193538/build-llvm/tools/clang/runtime/compiler-rt/clang_linux/full-x86_64/x86_64/SubDir.lib/addvsi3.o
/tmp/buildd/llvm-toolchain-snapshot-3.4~svn193538/projects/compiler-rt/lib/addvsi3.c
/usr/include/clang/3.4/include/module.map:1:8: error:
/usr/include/clang/3.4/include/module.map:1:8: error: redefinition of
module '_Builtin_intrinsics'
redefinition of module '_Builtin_intrinsics'
module _Builtin_intrinsics [system] {module _Builtin_intrinsics [system] {
       ^
/tmp/buildd/llvm-toolchain-snapshot-3.4~svn193538/build-llvm/Release+Asserts/bin/../lib/clang/3.4/include/module.map:1:8:
note: previously defined here
module _Builtin_intrinsics [system] {
       ^

Any ideas on how to fix that ?

Thanks,
Sylvestre

Any particular invocation of Clang should only find the built-in headers
corresponding to that binary; it should look in $(dirname
$argv0)/../lib/clang/3.4/include for those. Can you run the build command
with -v and try to figure out why the include path contains both
/usr/include/clang/3.4/include and .../bin/../lib/clang/3.4/include? (Which
of these corresponds to the clang binary being used, and why is the other
one on the include path?)

The Debian clang package is patched to search also in /usr/include/clang/3.4/include Anyway, module.map should not included twice. Thanks, Sylvestre Full log: Selected GCC installation: “/pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/build-llvm/Release/bin/clang” -cc1 -triple x86_64-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name absvdi2.c -mrelocation-model pic -pic-level 2 -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version 2.23.90.20130927 -momit-leaf-frame-pointer -v -coverage-file /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/build-llvm/tools/clang/runtime/compiler-rt/clang_linux/full-x86_64/x86_64/SubDir.lib/absvdi2.o -resource-dir /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/build-llvm/Release/bin/…/lib/clang/3.4 -isysroot /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/projects/compiler-rt/SDKs/linux -internal-isystem /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/projects/compiler-rt/SDKs/linux/usr/local/include -internal-isystem /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/build-llvm/Release/bin/…/lib/clang/3.4/include -internal-isystem /usr/include/clang/3.4/include/ -internal-externc-isystem /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/projects/compiler-rt/SDKs/linux/usr/include/x86_64-linux-gnu -internal-externc-isystem /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/projects/compiler-rt/SDKs/linux/usr/include/x86_64-linux-gnu -internal-externc-isystem /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/projects/compiler-rt/SDKs/linux/usr/include -O3 -Wall -Werror -fdebug-compilation-dir /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/build-llvm/tools/clang/runtime/compiler-rt -ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -vectorize-loops -vectorize-slp -o /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/build-llvm/tools/clang/runtime/compiler-rt/clang_linux/full-x86_64/x86_64/SubDir.lib/absvdi2.o -x c /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/projects/compiler-rt/lib/absvdi2.c clang -cc1 version 3.4 based upon LLVM 3.4 default target x86_64-pc-linux-gnu ignoring nonexistent directory “/pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/projects/compiler-rt/SDKs/linux/usr/local/include” ignoring nonexistent directory “/pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/projects/compiler-rt/SDKs/linux/usr/include/x86_64-linux-gnu” ignoring nonexistent directory “/pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/projects/compiler-rt/SDKs/linux/usr/include/x86_64-linux-gnu” #include “…” search starts here: #include <…> search starts here: /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/build-llvm/Release/bin/…/lib/clang/3.4/include /usr/include/clang/3.4/include /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/projects/compiler-rt/SDKs/linux/usr/include End of search list. /usr/include/clang/3.4/include/module.map:1:8: error: redefinition of module ‘_Builtin_intrinsics’ module _Builtin_intrinsics [system] { ^ /pro/pkg-llvm/llvm-toolchain/branches/llvm-toolchain-snapshot-3.4~svn193603/build-llvm/Release/bin/…/lib/clang/3.4/include/module.map:1:8: note: previously defined here module _Builtin_intrinsics [system] { ^ 1 error generated.

Hello,

Recently, compiler-rt build started to fail when the package are also
installed on the system.

  COMPILE: clang_linux/full-x86_64/x86_64:

/tmp/buildd/llvm-toolchain-snapshot-3.4~svn193538/projects/compiler-rt/lib/addvsi3.c

/tmp/buildd/llvm-toolchain-snapshot-3.4~svn193538/build-llvm/Release+Asserts/bin/clang
-fPIC -Wall -Werror -O3 -fomit-frame-pointer -m64

--sysroot=/tmp/buildd/llvm-toolchain-snapshot-3.4~svn193538/projects/compiler-rt/SDKs/linux
-c -o

/tmp/buildd/llvm-toolchain-snapshot-3.4~svn193538/build-llvm/tools/clang/runtime/compiler-rt/clang_linux/full-x86_64/x86_64/SubDir.lib/addvsi3.o

/tmp/buildd/llvm-toolchain-snapshot-3.4~svn193538/projects/compiler-rt/lib/addvsi3.c
/usr/include/clang/3.4/include/module.map:1:8: error:
/usr/include/clang/3.4/include/module.map:1:8: error: redefinition of
module '_Builtin_intrinsics'
redefinition of module '_Builtin_intrinsics'
module _Builtin_intrinsics [system] {module _Builtin_intrinsics [system] {
       ^

/tmp/buildd/llvm-toolchain-snapshot-3.4~svn193538/build-llvm/Release+Asserts/bin/../lib/clang/3.4/include/module.map:1:8:
note: previously defined here
module _Builtin_intrinsics [system] {
       ^

Any ideas on how to fix that ?

Any particular invocation of Clang should only find the built-in headers
corresponding to that binary; it should look in $(dirname
$argv0)/../lib/clang/3.4/include for those. Can you run the build command
with -v and try to figure out why the include path contains both
/usr/include/clang/3.4/include and .../bin/../lib/clang/3.4/include? (Which
of these corresponds to the clang binary being used, and why is the other
one on the include path?)

The Debian clang package is patched to search also in
/usr/include/clang/3.4/include

That will do the wrong thing for any clang that is not installed -- it'll
find the system clang's builtin headers and its own.

Anyway, module.map should not included twice.

Hmm, we could use the relative positions in the include path to resolve
redefinitions of modules (that is, use the same rules we use to resolve
ambiguous #include names). We'd still need to load the modules from both
places in case one of them #include_next's a header from the other one, but
we could resolve what the module name means if it appears in an @import or
similar.

In this case, that's *still* not going to do the right thing, even though
it may make the symptoms go away for now -- for instance, <stdint.h> has an
#include_next, and you really don't want that to go pulling in the builtin
headers from the wrong build of Clang. You should fix your clang patch to
search in a smarter way: maybe you could look for
"$argv0/../include/clang/3.4/include" instead of looking for an absolute
path?

I implemented this solution. It seems it will do the job.
Thanks for the suggestion.

Sylvestre