<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 21, 2014 at 2:09 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 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>> 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>
</div>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.</blockquote></div><br>Please see my comment that specifically addressed this: this would be a radical change in how libc++ is built and distributed from its historical process. We can argue whether that is good or bad, but its absolutely not something we can change at the drop of a hat yet. I'd at least like Marshall and some of the BSDs that are currently shipping libc++ to comment on such a change.</div>
<div class="gmail_extra"><br>It would be *really* bad if Linux expected libc++ to be part of the compiler's tree of libraries and headers, but FreeBSD, Darwin, and every other OS expected it to be part of the OS or system root.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">We can fix this issue with a smaller change though. In the same way we currently check to see if the GCC installation is inside of the requested system root and add its parent 'lib' directory to the library search paths, we can check if the Clang installation is inside of the requested system root and do the same.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">If we want to follow the practice of GCC here (which I'm actually of two minds about, I see both sides) then the correct way to handle this is likely to build per-target trees. GCC cross compilers install libraries into <prefix>/<target-triple>/lib (relative to <prefix>/bin/<target-triple>-gcc). We could do something similar, but I'm hesitant to go this route without some significant buy in across platforms. I would really like to have at least some consistency and sanity in how we build Clang as a cross compiler and libc++ as a standard library targeting various different platforms.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">-Chandler</div></div>