PDA

View Full Version : clang fails at stl include



qonfused
8th February 2012, 08:29 PM
I was wanting to try out clang/clang++, so I tried to change the compiler of one off my current projects. That failed. It gave a bunch of errors at the inclusion of basic standard library headers. I confirmed the issue with this simple piece of code:

main.cxx:


#include <string>
#include <iostream>
using namespace std;

int main()
{
std::string s("Hi world!!!");
cout << s << endl;
return 0;
}


compiling gives the following


$ clang++ main.cxx -o main
In file included from main.cxx:1:
In file included from /usr/include/c++/4.6.2/string:41:
In file included from /usr/include/c++/4.6.2/bits/char_traits.h:40:
/usr/include/c++/4.6.2/bits/stl_algobase.h:378:43: error: unexpected type name '_ValueTypeI': expected expression
const bool __simple = (__is_trivial(_ValueTypeI)
^
/usr/include/c++/4.6.2/bits/stl_algobase.h:383:40: error: non-type template argument of type 'const bool' is not an integral constant expression
return std::__copy_move<_IsMove, __simple,
^~~~~~~~
...


FYI:


$ cat /etc/system-release
Fedora release 16 (Verne)
$ clang --version
clang version 2.9 (tags/RELEASE_29/final)
Target: x86_64-redhat-linux-gnu
Thread model: posix


help!

fedvasu
9th February 2012, 02:33 AM
Ok , I thought i was the only person in the world concerned about huge broken-ness of clang++ on Linux and fedora in particular.

All the following doesn't apply if clang++ works on any other latest linux distro (ubuntu post 10.10 , mint 11 and above, opensuse 12.x etc)

----my dirtiest rant-------
clang developers are nuts , they consider simple stylistic differences in code as errors , the goal of the clang project is to develop a compiler "which pisses on the developer the moment he starts typing!!" , we'll may be google and apple (main developers from) want to distill crappy programmers and recruit self-indulging , safety, &security geeks , who masturbate on their own code.
The entire effort is futile , to generate very strict diagnostics for horrible language like c++ (it is powerful,useful but horrible(ugly)) , almost all-code would be eroneous , thats what it says when it sees , the code of include files isn't stylized to match their *****. clang++ atleast on fedora out-of-reach!!
-----------------------

all said and done , the fedora packagers are doing everything possible to fix it , heck even gcc-core dev , jakub has tried fixing it, but he has failed so far as everyone.

either g++ is f**ked up or clang developers have malicious intent of giving gcc a bad name (very much possible!!)

there are atleast 10 threads around this issue.

i say forget developing c++ with clang compiler on linux , i bet it works like a charm on mac os x (i bet!!)
use g++, enjoy the fun of 4 page error messages, it's all good (yeah i know its not)

It's been 3 releases of fedora , clang++ is so f'd up! by the way i think , fedora should drop clang altogether,now that atleast 10-20 paclkages are dropped every release , last release it was linuxdcpp, prior to that miro , why bother maintaining a c++ compiler which no-one benefits from(except for the clang developers) , ok it has less spitting c compiler part , but still not worth the sh**.


anyway clang++ is narcisist compiler!! gcc is your friend!!

qonfused
9th February 2012, 03:04 AM
Hi fedvasu, thanks for the reply!

I like the concept as presented here: link (http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/Clang-Defending-C-from-Murphy-s-Million-Monkeys). Meaningful warnings with suggestions for fixes. I prefer dealings with warnings from the compiler to bugs at run-time.

My colleague had it working straight out of the box using Gentoo...

fedvasu
9th February 2012, 05:42 AM
Hi fedvasu, thanks for the reply!


My colleague had it working straight out of the box using Gentoo...

I know abou the promise of clang , but it's just aggravation for me :) and Gentoo huh!!

Finally a distro where clang++ works :dance:, if you really need clang++ perhaps you get a gentoo box , once done developing using clang , you can recompile your project using g++ , I strongly recomend NOT TO
use gentoo on your main workstation or developing machine.(unless you have experience with gentoo)

sorry for the rant, it is just pure-frustration :(

gentoo gets the latest packages superfast, as it is a source-based bleeding edge distro maybe it is fixed in clang-3.0 !!

I hope this fix finally arrives in fedora too :)

qonfused
9th February 2012, 01:06 PM
Hi again,

Rant all you want; I don't mind. I get frustrated as well when **** i expect to work does not.

Good news though. I pulled the llvm/clang src off repo. and compiled. It worked without problems. I also tested it on the small "hello world" example given earlier, and i tested it on the larger project mentioned earlier. It also seems to have worked flawlessly. I guesstimate the build time to be 2-3 times longer then gcc, but just glancing at the output i see that the warnings are allot more helpful. I have not extensively tested it, but the qt gui started without any flaw, as far as i can tell. Hura!

I roughly followed the guide from their site: clang/get_started (http://clang.llvm.org/get_started.html), with the notable exception that i used RELEASE_30/rc4/ as apposed to trunk, and built using cmake.

I don't know the first thing about building rpm packages, but I suspect if the issue with the fedora package will be resolved by moving to 3.0, or the fault is not with the wonderful people at clang (wonderful, if only because they highlight the importance of good warnings messages).

cheers
q

PS: I re-read your "dirtiest rant", In case you did not know, you can suppress warnings from includes using the -isystem flag with gcc. I have no idea how to get the same behavior out of clang. However, the default of clang (3.0) seems to be to consider stl includes as "-isystem" because clang has not thrown a single warning regarding stl headers in my tests. CMake seems to know how to make clang use includes as "system includes" though. In my project i have a few include_directories(SYSTEM /somelib/incl/) which would cause any compiler to spew warnings like there was no tomorrow unless treated as "system includes".