r199632 - Make the Linux support for finding libc++ somewhat less braindead.

[Alexey Samsonov]

On Tue, Jan 21, 2014 at 2:20 PM, Chandler Carruth <chandlerc at google.com> wrote:
>
> On Tue, Jan 21, 2014 at 2:09 AM, Alexey Samsonov <samsonov at google.com>
> wrote:
>>
>> On Tue, Jan 21, 2014 at 1:12 PM, Evgeniy Stepanov
>> <eugeni.stepanov at gmail.com> wrote:
>> > On Tue, Jan 21, 2014 at 1:06 PM, Chandler Carruth <chandlerc at google.com>
>> > wrote:
>> >> On Tue, Jan 21, 2014 at 12:06 AM, Evgeniy Stepanov
>> >> <eugeni.stepanov at gmail.com> wrote:
>> >>>
>> >>> I don't this adding builddir/lib to linker search path would be right.
>> >>
>> >>
>> >> Why not?
>> >
>> > Because at the moment it contains a bunch of host libraries, and
>> > libc++ we are trying to link is a target library. Of course, at the
>> > moment it is being built with the host compiler, but it is a target
>> > library in spirit.
>>
>> Exactly. Can we build libc++ in somewhere like
>> <build-dir>/lib/x86_64-linux-gnu/libc++.so
>> instead of <build-dir>/lib/libc++.so as we do now? We can later
>> generalize this to build multiple
>> versions of libc++ for different target arches, and we can teach Clang
>> to look for libc++ in
>> a target-specific directory.


Opened http://llvm.org/bugs/show_bug.cgi?id=18569

>
>
> 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.
>
> 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.
>
>
> 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.

What if Clang installation is not in the system root, but we simply
provide fresh Clang
to bootstrap using -DCMAKE_C_COMPILER=/usr/funky/path/bin/clang ?
Chances are I don't understand --sysroot thing properly. Or do you
suggest to add additional
flags to Clang when we configure the build tree with LLVM_ENABLE_LIBCXX ?

>
>
> 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.
>
> -Chandler



-- 
Alexey Samsonov, MSK