llvm dev - Jul 2015 - [LLVMdev] Purpose of LLVM_ENABLE_LIBCXX and LLVM_ENABLE_LIBCXXABI

Hi Renato

I had the impression that Michael actually wanted the latter, like
GCC
> has autoconf options to change the default behaviour of the compiler
> at build time.
>
> I may be wrong, though.

yes I thought that was what he wanted because he said

Are they used to indicate that if the C/C++ compiler for building LLVM
is
> clang
>
That combined with the standard cmake flags cmake_cxx_compiler and
cmake_c_compiler should result in the host being clang and using libc++ and
libc++abi
I was a little thrown off by the wording of the question
I think you are more correct though I misread the second part of the
question where he said what he actually wanted the resulting compiler to
use libc++
Sorry for the noise

Michael

In short Michael it should not matter if clang was build with libc++ or
libstdc++ the resulting compiler can use both after the fact
As Renato described above in more detail LDFLAGS="--stdlib=libc++ -lc++abi
-lunwind" would be used to tell that resulting compiler to link its
programs with libc++, libc++abi and libunwind
Rather than using libstdc++ and libgcc_eh

If you want to know how to change the default to do this without touching
the LDFLAGS for your target this you must look in the clang repo under
lib/driver
If you have any trouble doing this I'd be glad to help you change the
default behavior if let me know what your target is.

Kind Regards
Martell

On Tue, Jul 28, 2015 at 1:06 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 28 July 2015 at 12:10, Schlottke-Lakemper, Michael
> <m.schlottke-lakemper at aia.rwth-aachen.de> wrote:
> > I am wondering about the meaning of the cmake flags LLVM_ENABLE_LIBCXX
> and LLVM_ENABLE_LIBCXXABI. Are they used to indicate that if the C/C++
> compiler for building LLVM is clang, and if this clang has support for
> libc++ with libc++Abi, that both lib++ and libc++abi should be used
> (instead of linking to the default, which at least on Linux is libstdc++)?
> If not, what is the canonical way of building LLVM with libc++? I am asking
> since I seem to have problems linking libLLVMSupport.a to a program while
> using clang with libc++, whereas the used clang/LLVM compiler was
> originally built with clang and libstdc++.
>
> Hi Michael,
>
> Just cloning the libc++ / libc++abi / libunwind repositories in
> llvm/projects (or symlinking them there) is enough for CMake to pick
> it up, build and test on check-all. The libraries will be available on
> build/lib.
>
>
> > Related to the first question: do the above flags also make clang use
> libc++ by default, or is this configurable via a different set of flags?
>
> No. I believe this is an old flag when that wasn't enable by default
> (and now it's used to disable it if you have the dirs). But maybe
> heavier users of libc++ can help you there.
>
> You still have to use LDFLAGS="--stdlib=libc++ -lc++abi -lunwind"
and,
> if you're not installing it anywhere (but using the build directory),
> add LD_LIBRARY_PATH=build/lib to your environment.
>
> If you run into inconsistencies because libgcc_s / libgcc_eh are
> included, or if libstdc++ is included as well, you may have to use
> -nostdlibc++ to clean up the internal options, and then use --stdlib
> and friends to create a new set.
>
> It is confusing, but we don't want to make those libraries the default
> on any environment that might still need/use libstdc++/libgcc by
> default. This is more of a system-wide decision. For testing purposes,
> though, it works well.
>
> cheers,
> --renato
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150728/fb1c7a89/attachment.html>

>
> I think you are more correct though
Meant to say more likely correct. :)

I don't have an ego problem this was a typo

Michael
> In short Michael
>
Also said his name twice,
I need to start reading things twice before I click the send button

On Tue, Jul 28, 2015 at 1:40 PM, Martell Malone <martellmalone at
gmail.com>
wrote:
> Hi Renato
>
> I had the impression that Michael actually wanted the latter, like GCC
>> has autoconf options to change the default behaviour of the compiler
>> at build time.
>>
>> I may be wrong, though.
>
>
> yes I thought that was what he wanted because he said
>
> Are they used to indicate that if the C/C++ compiler for building LLVM is
>> clang
>>
>
> That combined with the standard cmake flags cmake_cxx_compiler and
> cmake_c_compiler should result in the host being clang and using libc++ and
> libc++abi
> I was a little thrown off by the wording of the question
> I think you are more correct though I misread the second part of the
> question where he said what he actually wanted the resulting compiler to
> use libc++
> Sorry for the noise
>
> Michael
>
> In short Michael it should not matter if clang was build with libc++ or
> libstdc++ the resulting compiler can use both after the fact
> As Renato described above in more detail LDFLAGS="--stdlib=libc++
-lc++abi
> -lunwind" would be used to tell that resulting compiler to link its
> programs with libc++, libc++abi and libunwind
> Rather than using libstdc++ and libgcc_eh
>
> If you want to know how to change the default to do this without touching
> the LDFLAGS for your target this you must look in the clang repo under
> lib/driver
> If you have any trouble doing this I'd be glad to help you change the
> default behavior if let me know what your target is.
>
> Kind Regards
> Martell
>
> On Tue, Jul 28, 2015 at 1:06 PM, Renato Golin <renato.golin at
linaro.org>
> wrote:
>
>> On 28 July 2015 at 12:10, Schlottke-Lakemper, Michael
>> <m.schlottke-lakemper at aia.rwth-aachen.de> wrote:
>> > I am wondering about the meaning of the cmake flags
LLVM_ENABLE_LIBCXX
>> and LLVM_ENABLE_LIBCXXABI. Are they used to indicate that if the C/C++
>> compiler for building LLVM is clang, and if this clang has support for
>> libc++ with libc++Abi, that both lib++ and libc++abi should be used
>> (instead of linking to the default, which at least on Linux is
libstdc++)?
>> If not, what is the canonical way of building LLVM with libc++? I am
asking
>> since I seem to have problems linking libLLVMSupport.a to a program
while
>> using clang with libc++, whereas the used clang/LLVM compiler was
>> originally built with clang and libstdc++.
>>
>> Hi Michael,
>>
>> Just cloning the libc++ / libc++abi / libunwind repositories in
>> llvm/projects (or symlinking them there) is enough for CMake to pick
>> it up, build and test on check-all. The libraries will be available on
>> build/lib.
>>
>>
>> > Related to the first question: do the above flags also make clang
use
>> libc++ by default, or is this configurable via a different set of
flags?
>>
>> No. I believe this is an old flag when that wasn't enable by
default
>> (and now it's used to disable it if you have the dirs). But maybe
>> heavier users of libc++ can help you there.
>>
>> You still have to use LDFLAGS="--stdlib=libc++ -lc++abi
-lunwind" and,
>> if you're not installing it anywhere (but using the build
directory),
>> add LD_LIBRARY_PATH=build/lib to your environment.
>>
>> If you run into inconsistencies because libgcc_s / libgcc_eh are
>> included, or if libstdc++ is included as well, you may have to use
>> -nostdlibc++ to clean up the internal options, and then use --stdlib
>> and friends to create a new set.
>>
>> It is confusing, but we don't want to make those libraries the
default
>> on any environment that might still need/use libstdc++/libgcc by
>> default. This is more of a system-wide decision. For testing purposes,
>> though, it works well.
>>
>> cheers,
>> --renato
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150728/29e952f8/attachment.html>

>
> That's how I read it. :)
:)

Adding a little to the topic what criteria would we need to make a target
use compiler-rt and libc++ as the default in the clang driver.
I have successfully built a standalone clang toolchain with mingw-w64
without using gcc or binutils.
Currently I locally patch this to be the default.


On Tue, Jul 28, 2015 at 2:33 PM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 28 July 2015 at 14:14, Martell Malone <martellmalone at gmail.com>
wrote:
> > Meant to say more likely correct. :)
>
> That's how I read it. :)
>
> cheers,
> --renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150728/0360250a/attachment.html>

On 28 July 2015 at 14:44, Martell Malone <martellmalone at gmail.com>
wrote:
> Adding a little to the topic what criteria would we need to make a target
> use compiler-rt and libc++ as the default in the clang driver.
> I have successfully built a standalone clang toolchain with mingw-w64
> without using gcc or binutils.
There was another discussion with David Chisnall, where he gave a good
overall on some of the complications for doing so:

http://comments.gmane.org/gmane.comp.compilers.clang.devel/44037
>From my point of view, we can only do something that radical when we
can test on most environments and make sure that any combination will
work. I don't know how to do that, though, but I expect that there
should be enough tests in Clang to that effect.

For now, I just want to make sure it works on ARM/AArch64, even if I
have to hack my way through it. If I can have at least a buildbot
testing them, we'll be sure not to regress in functionality. System
integration is a secondary issue.

cheers,
--renato