It has come up when reviewing Kostya's patch to add the necessary support fort linking in the Address Sanitizer runtime library that we need a proper scheme and plan for deploying runtime libraries along with Clang.<div>
<br></div><div>I've CC'ed llvmdev on this for compiler-rt developers' input.</div><div><br></div><div>The key issues I see when locating runtime libraries are the following:</div><div><br></div><div>- These libraries should be shipped with Clang, not installed separately on the system.</div>
<div>- They are likely to be somewhat tied to specific versions of Clang/LLVM.</div><div>- To support cross-compiling, we should be able to install multiple copies of these libraries in a single Clang installation, and use the appropriate one when targeting a particular platform.</div>
<div>- The above cross-compiling concern extends to ABI compatibility -- many of the ABIs are already fixed in this space.</div><div>- These are different from builtin header files which can use the preprocessor to internally differentiate their contents based on the target platform.</div>
<div><br></div><div>My proposed solution:</div><div><br></div><div>- Base the path on the shared "resource directory" concept which already exists in Clang.</div><div>  - Builtin header files are at <ResourceDir>/include already.</div>
<div>- Append a "base" triple directory name.</div><div>- Append a "lib" directory name for runtime libraries</div><div>- Place the runtime libraries as "libcompiler_rt_<sublib>.a" for each sub-library component "<sublib>".</div>
<div><br></div><div>Example for "x/bin/clang" installation:</div><div>  x/bin/../lib/clang/3.1/x86_64-linux-gnu/lib/libcompiler_rt_asan.a</div><div><br></div><div>What is a "base" triple? It is the simplest form we can reduce a triple to while guaranteeing compatibility. The concept is best explained by an example. All of the following triples reduce to the base triple of "x86_64-linux-gnu":</div>
<div>  x86_64-linux-gnu</div><div>  x86_64-pc-linux-gnu</div><div>  x86_64-unknown-linux-gnu</div><div>  x86_64-redhat-linux</div><div>  x86_64-redhat-linux6E</div><div>  ...</div><div><br></div><div>A different ABI could be expressed much like ARM's is with the last element: "*-gnueabi". This would *not* reduce to the triple ending in '-gnu'. Due to the adhoc and poorly spec'ed nature of existing triples, this will largely be a fixed mapping much like already exists in the Clang driver, but consolidated into LLVM's core triple logic.</div>
<div><br></div><div><br></div><div>Open Questions:</div><div><br></div><div>How do we handle 'i686' vs 'i386'? Is it useful to have separate installed libraries for i386 and i686 in order to get better performance for the latter *and* maintain compatibility for the former? We could collapse to either i386 or i686, and define either to mean whatever we want (for example, Debian uses i386-linux-gnu for its "base" triple in multiarch, and does *not* support i386 processors).</div>
<div><br></div><div>This scheme closely mirrors GCC's existing scheme with one exception: GCC puts the triple first, and the version number second. I don't think this matters greatly either way, but currently Clang puts its version number first. I think this reflects the inherent design of Clang to be cross-compiling by default, but it would be good to consider (even if we reject) matching GCC's behavior here.</div>
<div><br></div><div>Should runtime libraries be installed as archives? .o files? .so files? (gasp) bitcode? Some mixture of these? What mixture, and how do we decide? I lean  toward .o files as bitcode where the linker supports it, normal .o files where it supports those, and .a files only as a fallback. Not very confident of these preferences though.</div>