[LLVMdev] [ exception_ptr ] libcxx doesn't cope well with libcxxabi under linux

[Emanuele Cestari]

I understand that there are alternatives but in my opinion there are some subtle messages that suggest otherwise scattered all around the llvm project and sub-projects, let me give you a list of what I think should be more explicit or done differently:

 - the official binary packages ( from llvm.org/releases/download.html ) for clang include libcxx headers, suggesting that there some kind of full or official support for libcxx under Ubuntu or any other GNU/Linux based distribution

 - the official libcxxabi website states that libcxxabi is complete and there is full support for linux, even the matrix tracking the current status of the project confirms that http://libcxxabi.llvm.org/spec.html

 - the cmake based build makes this weird difference between libstdc++ and libsupc++ and both names are accepted as ABI options, libstdc++ is not an ABI library, this is highly misleading for newcomers and I still don't have a good idea about why that option is there


Generally speaking there is also the word "linux" that is misleading in my opinion, this word it's scattered all around the llvm docs and projects, and if you ask me what is a typical "linux" based system, I would say any system with a GNU/Linux distribution installed using libstdc++ as the standard C++ library and libsupc++ or libcxxrt as the ABI library . Even some router or a generic Android based hardware can be labeled as a "linux" system.


Now I understand that with the word "linux" the developers mean some generic IBM machine running the linux kernel plus some in-house developed standard library.

I think that the guidelines should make this more explcit, meaning blacklisting the use of a generic word such as "linux" in such cases, but force to always describe the targeted system in a more unique and specific way, just like the triple does, in any doc or reference to any project there should be an explicit reference to the name of the ABI, the name of the standard library, the configuration of the system that it's used to run the test, if the given project or a part of it is vendor specific and so on; just 3 or 4 names that can make a big difference. 


Plus the official releases for an unsupported platform shouldn't include a project or a part of it that is unsupported for the given platform, even if you give me the header for libcxx, I'm using libstdc++ and libsupc++ anyway, why bothering including a misleading option that I will not be able to use and I'm inclined to label as "broken" judging from what I get from the official website.


I think that minor changes in the policy can really make a difference and make the llvm project more reliable in its entirety.

Il Giovedì 1 Maggio 2014 21:00, Konstantin Tokarev <annulen at yandex.ru> ha scritto:
 

01.05.2014, 20:18, "Emanuele Cestari" <emanuelecestari at yahoo.com>:
> Since the original buildit script doesn't cover my needs I switched to a custom but really similar script, in the meantime I also got the habit to dig for new flags and support and the __GLIBCXX__ define was hiding some of this errors. I see that other linux-based operating system offer this kind of support and they even use the same core components of my GNU/Linux distribution.
>
> You are right, in the end I get this warnings but how I'm supposed to fill the voids ? In other words why I should user libc++ under linux and what are the benefits ? I should go for libstdc++ and libsupc++ ?

You can try libcxxrt instead of libc++abi


-- 
Regards,
Konstantin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140501/1c9308a2/attachment.html>