<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Dec 19, 2017 at 8:33 AM Jonathan Roelofs <<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 12/19/17 9:15 AM, Petr Hosek via llvm-dev wrote:<br>
> Today, there're two different locations for runtimes files within<br>
> Clang's installation:<br>
><br>
> compiler-rt:<br>
>    headers: $prefix/lib/clang/$version/include(/sanitizer)<br>
>    libraries:<br>
> $prefix/lib/clang/$version/lib/$os/libclang_rt.$name-$arch.$ext<br>
><br>
> libc++, libc++abi, libunwind:<br>
>    headers: $prefix/include/c++/v1<br>
>    libraries: $prefix/lib/$name.$ext<br>
><br>
> The scheme used by libc++, libc++abi, libunwind doesn't support targets<br>
> other than the host which is a problem when cross-compiling.<br>
<br>
Yes, it does: --sysroot=<br></blockquote><div><br></div><div>What if my sysroot doesn't contains C++ library, or even if it does I may still want to use libc++ shipped with the toolchain e.g. because the one that's part of the sysroot doesn't support C++17? </div><div><br></div><div>I don't like the "build libc++ separately and then put it inside your sysroot" solution for several reasons, most importantly because the sysroot typically considered read-only e.g. I cannot modify Xcode's sysroot replacing whatever libc++ is already there, but I can use libSystem.dylib from Xcode's sysroot with my own libc++ version. In our case also we ship the toolchain separately from the sysroot at different frequencies because they come from different source and system libraries change far less often than libc++.</div><div><br></div><div>What this means in practice is that when cross-compiling you have to do something like:</div><div><br></div><div>clang++ --target=<arch>-<vendor>-<os> --sysroot=/path/to/sysroot -stdlib=libc++ -nostdinc++ -I<libc++-install-prefix>/include/c++/v1 -L<libc++-install-prefix>/lib</div><div><br></div><div>This is even when the C++ library for your target is part of your Clang toolchain so the driver arguably should know how to find it without you having to duplicate the driver logic.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What's currently missing is a standardized naming for a) where the<br>
sysroots live, and b) what they're named. Host libraries should continue<br>
to live in $prefix/{include, lib, lib32, lib64} as appropriate, whereas<br>
target libraries should live in something like:<br>
$prefix/clang-runtimes/$triple/$multilib/{usr/include, usr/lib, etc.}<br></blockquote><div><br></div></div><div dir="ltr"><div class="gmail_quote"><div>I don't care too much about what the path is going to be. However, it'd be nice if we could unify the paths between compiler-rt runtimes and libc++. I always assumed that $prefix/lib/clang/$version was the path for runtimes hence suggesting it.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  In our<br>
> toolchain, we would like to build runtimes for all host and target<br>
> platforms we support, e.g. a single toolchain will have runtimes for<br>
> x86_64 and aarch64 Linux, Fuchsia and Windows. All you need to provide<br>
> is the target triple and the sysroot. While this is possible with<br>
> builtins, sanitizers and other compiler-rt runtimes, it's not possible<br>
> with libc++, libc++abi, libunwind.<br>
><br>
> Our proposal is to move both compiler-rt and libc++, libc++abi,<br>
> libunwind into a new location that would support cross-compilation and<br>
> unify the layout:<br>
><br>
> headers: $prefix/lib/clang/$version/include(/$triple)(/c++/v1)<br>
> libraries: $prefix/lib/clang/$version/$triple/lib/$name.$ext<br>
<br>
I don't think it's a good idea to tie all the runtimes to the compiler<br>
like that. It makes sense for the builtins to live there since they are<br>
heavily coupled with the specific compiler version, but I'm not<br>
convinced libc++/libc++abi/libunwind should.<br></blockquote><div><br></div><div>They may be less tied than sanitizers because they don't rely on compiler instrumentation, but there's still some dependency, e.g. in order to use coroutines in libc++ I need a version of Clang that has the appropriate intrinsics.</div><div><br></div><div>I could build libc++ against an older version of Clang which will disable features not supported by that Clang version, but that version is again tied to that version of Clang.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> This means that for compiler-rt, the main difference would be moving the<br>
> runtime libraries to an target specific subdirectory rather than<br>
> including the architecture in the library name; for libc++, libc++abi,<br>
> libunwind, both headers and libraries will be moved to a new, target<br>
> specific location.<br>
><br>
> In terms of implementation, we'll need to modify the Clang driver to use<br>
> this location when looking for runtimes and C++ libraries and headers.<br>
> This should be a non-intrusive change: we'll modify the driver to look<br>
> into the new location in addition to the existing ones, so if the new<br>
> path doesn't exist, the driver will simply fallback to the existing<br>
> behavior. When this is done, we need to modify the CMake build to<br>
> install files into the new location.<br>
><br>
> This layout would be only used when runtimes are built as part of the<br>
> llvm/runtimes tree or using LLVM_ENABLE_RUNTIMES in the monorepo layout<br>
> (because this setup supports cross-compiling runtimes). When built as<br>
> part of LLVM or standalone, libc++, libc++abi, libunwind would still<br>
> install their files to $prefix/include and $prefix/lib as today.<br>
><br>
> Once the overall scheme is agreed upon, we could also consider<br>
> de-duplicating C++ headers across targets, by moving shared headers into<br>
> a common directory, with only varying subset in include/$triple.<br>
<br>
At the very least the __config_site headers cannot be de-duplicated.<br></blockquote><div><br></div><div>I think it should be sufficient to have separate __config headers for separate targets, that's really the only thing that differs.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Beyond that, I strongly disagree with de-duplicating them in general<br>
because it will break --sysroot= unless you add a bunch of symlinks...<br>
which don't exist on every host platform.</blockquote><div><br></div><div>I don't think you need symlinks, all you need is to put both include/c++/v1 and include/$triple/c++/v1 to your include paths, where the former contains all the common headers while the latter contains the target specific __config. This is exactly what GNU "multi-arch" layout does.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> To give an example, for x86_64 and aarch64 Linux, this would look like:<br>
><br>
> $prefix/lib/clang/6.0.0/include/sanitizer<br>
> $prefix/lib/clang/6.0.0/include/c++/v1<br>
> $prefix/lib/clang/6.0.0/include/x86_64-linux-gnu/c++/v1/__config<br>
> ...<br>
> $prefix/lib/clang/6.0.0/x86_64-linux-gnu/lib/<a href="http://libclang_rt.asan.so" rel="noreferrer" target="_blank">libclang_rt.asan.so</a><br>
> <<a href="http://libclang_rt.asan.so" rel="noreferrer" target="_blank">http://libclang_rt.asan.so</a>><br>
> $prefix/lib/clang/6.0.0/x86_64-linux-gnu/lib/libc++.so<br>
> ...<br>
> $prefix/lib/clang/6.0.0/aarch64-linux-gnu/lib/<a href="http://libclang_rt.asan.so" rel="noreferrer" target="_blank">libclang_rt.asan.so</a><br>
> <<a href="http://libclang_rt.asan.so" rel="noreferrer" target="_blank">http://libclang_rt.asan.so</a>><br>
> $prefix/lib/clang/6.0.0/aarch64-linux-gnu/lib/libc++.so<br>
> ...<br>
><br>
><br>
> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
><br>
<br>
--<br>
Jon Roelofs<br>
<a href="mailto:jonathan@codesourcery.com" target="_blank">jonathan@codesourcery.com</a><br>
CodeSourcery / Mentor Embedded / Siemens<br>
</blockquote></div></div></div>