<div dir="ltr">On Mon, 27 Sep 2021 21:33:43 +0300 Raul Tambre <<a href="mailto:raul@tambre.ee">raul@tambre.ee</a>> wrote:<br>> It is unclear to me why the symlink variant didn't work as previously when Clang <br><br><div><div class="gmail_default" style="font-family:verdana,sans-serif">Clang (or rather the standardC++ library) relies on the standard C++ library headers to be present in the search path before the /usr/include and such. CUDA wrappers and include files are added just before C++ library headers, because we need that to make things like `#include <complex>` work. Symlinking $CUDA/include -> /usr/include effectively places /usr/include very early in the search path and makes it impossible to intercept inclusions of headers that must be intercepted and that breaks compilation.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I've just landed <a href="https://reviews.llvm.org/rGfd582eeffe582665eacac522617a15e17e9872cd">https://reviews.llvm.org/rGfd582eeffe582665eacac522617a15e17e9872cd</a> which should move CUDA SDK includes down the search path, so making it a symlink to /usr/include should no longer break compilation.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">In general, I think a shim cuda.h header file is probably a safer approach than symlinking $CUDA/include to /usr/include.</div><div class="gmail_default" style="font-family:verdana,sans-serif">While it should be benign now, it does have potential to break things again if/when compiler needs to rearrange it's include search order. </div><div class="gmail_default" style="font-family:verdana,sans-serif">A shim cuda.h dues the bare minimum needed and will not be affected by compiler changes, nor will it break compiler's assumptions about include order.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><br></div></div>