<div dir="ltr"><div><div>I think we have a least to distinct cases here. >From a distribution (debian, ...) point of view, it makes sense to have libc++ installed as part of the OS / System root. On the other hand, if we want that our binary releases can be used to bootstrap latest llvm versions, we'd prefer not to depend on some misc libc++ found in the system, but use the one bundled with the binary release.<br>
<br></div>Cheers,<br>--<br></div>Arnaud<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 21, 2014 at 11:42 AM, Alexey Samsonov <span dir="ltr"><<a href="mailto:samsonov@google.com" target="_blank">samsonov@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Jan 21, 2014 at 2:20 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:<br>

><br>
> On Tue, Jan 21, 2014 at 2:09 AM, Alexey Samsonov <<a href="mailto:samsonov@google.com">samsonov@google.com</a>><br>
> wrote:<br>
>><br>
>> On Tue, Jan 21, 2014 at 1:12 PM, Evgeniy Stepanov<br>
>> <<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>> wrote:<br>
>> > On Tue, Jan 21, 2014 at 1:06 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>><br>
>> > wrote:<br>
>> >> On Tue, Jan 21, 2014 at 12:06 AM, Evgeniy Stepanov<br>
>> >> <<a href="mailto:eugeni.stepanov@gmail.com">eugeni.stepanov@gmail.com</a>> wrote:<br>
>> >>><br>
>> >>> I don't this adding builddir/lib to linker search path would be right.<br>
>> >><br>
>> >><br>
>> >> Why not?<br>
>> ><br>
>> > Because at the moment it contains a bunch of host libraries, and<br>
>> > libc++ we are trying to link is a target library. Of course, at the<br>
>> > moment it is being built with the host compiler, but it is a target<br>
>> > library in spirit.<br>
>><br>
>> Exactly. Can we build libc++ in somewhere like<br>
>> <build-dir>/lib/x86_64-linux-gnu/libc++.so<br>
>> instead of <build-dir>/lib/libc++.so as we do now? We can later<br>
>> generalize this to build multiple<br>
>> versions of libc++ for different target arches, and we can teach Clang<br>
>> to look for libc++ in<br>
>> a target-specific directory.<br>
<br>
<br>
</div>Opened <a href="http://llvm.org/bugs/show_bug.cgi?id=18569" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=18569</a><br>
<div class="im"><br>
><br>
><br>
> Please see my comment that specifically addressed this: this would be a<br>
> radical change in how libc++ is built and distributed from its historical<br>
> process. We can argue whether that is good or bad, but its absolutely not<br>
> something we can change at the drop of a hat yet. I'd at least like Marshall<br>
> and some of the BSDs that are currently shipping libc++ to comment on such a<br>
> change.<br>
><br>
> It would be *really* bad if Linux expected libc++ to be part of the<br>
> compiler's tree of libraries and headers, but FreeBSD, Darwin, and every<br>
> other OS expected it to be part of the OS or system root.<br>
><br>
><br>
> We can fix this issue with a smaller change though. In the same way we<br>
> currently check to see if the GCC installation is inside of the requested<br>
> system root and add its parent 'lib' directory to the library search paths,<br>
> we can check if the Clang installation is inside of the requested system<br>
> root and do the same.<br>
<br>
</div>What if Clang installation is not in the system root, but we simply<br>
provide fresh Clang<br>
to bootstrap using -DCMAKE_C_COMPILER=/usr/funky/path/bin/clang ?<br>
Chances are I don't understand --sysroot thing properly. Or do you<br>
suggest to add additional<br>
flags to Clang when we configure the build tree with LLVM_ENABLE_LIBCXX ?<br>
<div class="im HOEnZb"><br>
><br>
><br>
> If we want to follow the practice of GCC here (which I'm actually of two<br>
> minds about, I see both sides) then the correct way to handle this is likely<br>
> to build per-target trees. GCC cross compilers install libraries into<br>
> <prefix>/<target-triple>/lib (relative to <prefix>/bin/<target-triple>-gcc).<br>
> We could do something similar, but I'm hesitant to go this route without<br>
> some significant buy in across platforms. I would really like to have at<br>
> least some consistency and sanity in how we build Clang as a cross compiler<br>
> and libc++ as a standard library targeting various different platforms.<br>
><br>
> -Chandler<br>
<br>
<br>
<br>
</div><div class="HOEnZb"><div class="h5">--<br>
Alexey Samsonov, MSK<br>
_______________________________________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br></div>