about summary refs log tree commit diff
path: root/elf/dl-conflict.c
diff options
context:
space:
mode:
authorEmilio Cobos Álvarez <emilio@crisal.io>2019-11-12 19:18:32 +0100
committerFlorian Weimer <fweimer@redhat.com>2019-11-21 17:54:16 +0100
commitbfa864e1645e140da2e1aae3cf0d0ba0674f6eb5 (patch)
tree90e6be87b502b09bf30cb6f902f1b0ebab6830e0 /elf/dl-conflict.c
parent854e91bf6b4221f424ffa13b9ef50f35623b7b74 (diff)
downloadglibc-bfa864e1645e140da2e1aae3cf0d0ba0674f6eb5.tar.gz
glibc-bfa864e1645e140da2e1aae3cf0d0ba0674f6eb5.tar.xz
glibc-bfa864e1645e140da2e1aae3cf0d0ba0674f6eb5.zip
Don't use a custom wrapper macro around __has_include (bug 25189).
This causes issues when using clang with -frewrite-includes to e.g.,
submit the translation unit to a distributed compiler.

In my case, I was building Firefox using sccache.

See [1] for a reduced test-case since I initially thought this was a
clang bug, and [2] for more context.

Apparently doing this is invalid C++ per [cpp.cond], which mentions [3]:

> The #ifdef and #ifndef directives, and the defined conditional
> inclusion operator, shall treat __has_include and __has_cpp_attribute
> as if they were the names of defined macros.  The identifiers
> __has_include and __has_cpp_attribute shall not appear in any context
> not mentioned in this subclause.

[1]: https://bugs.llvm.org/show_bug.cgi?id=43982
[2]: https://bugs.llvm.org/show_bug.cgi?id=37990
[3]: http://eel.is/c++draft/cpp.cond#7.sentence-2

Change-Id: Id4b8ee19176a9e4624b533087ba870c418f27e60
Diffstat (limited to 'elf/dl-conflict.c')
0 files changed, 0 insertions, 0 deletions