Support for GCC 4.8
-
Hello,
I am working on a project and I want GCC 4.8 support if at all possible. On the desktop and more importantly targeting ARM (actually ARM5 if possible).
Development is currently on Ubuntu Linux 10.04 LTS. Possibly we upgrade that too, and/or ugprade our GCC 4.4 to GCC 4.8.
This so we can leverage language standards we'll want to support lambdas and such, Boost.Spirit2, and so on.
Regards,
Michael
-
GCC 4.8 is awfully slow, I would personally use 4.7 or clang. Are you sure your ARM board will actually work with new GCC?
OK, now, you did not ask any questions, so I could leave it at that, but I guess you are interested in using Qt with GCC 4.8. Short answer: does not work. Longer answer: there are pending patches under review, Qt 5.0.2 and 5.1 should get them if problems are resolved (it seems that for some people compilation works, while others get some nasty errors).
I don't know if there are plans to backport GCC4.8 support to Qt4, but it's sure likely to happen.
-
Well, the short answer is, I don't know. I am on a fact finding, establish the tool chain, mission.
Our application will require some sort of EBNF type parsing going on. I would like to utilize the boost library, in particular spirit2 for this. As well as language features like lambdas and better threading support available in GCC 4.8 C++11.
I'll admit, that may be ambitious with the overhead of compiler, language features, EBNF parser generators and all. But that's the animal we're trying to tame here.
I don't think we're that attached to 4.8.4 (currently), so if we need to establish a more forward thinking tool chain like Qt 5.0.2 (Commercial SDK?), that would be fine as well as far as I am concerned.
I am a also little out of my comfort zone discussing embedded processors. My limited understanding is, that as long as the thing builds to native (?) Linux x86 code, the ARM5 cross compilation is actually an after thought: i.e. I am not as interested in compiling to native ARM, I want the language features before I care about performance, per se.
I reserve the right to change my mind on any of that, of course. Assuming any of that's been addressed, will likely structure my process just using "simple" library and application PRO/PRI structure. A bit off topic, but germane to the Qt Creator tool chain decision making process nonetheless.
I do appreciate the feedback. Thank you.
-
I'm not that experienced with ARM either.
Good to hear you are happy with Qt5. Be sure to compile it yourself with C++11 support turned on. A lot of core internal stuff (QVector, QString, etc.) has been updated in Qt5 to use C++11 features. Prebuilt packages available from Qt-Project and Digia are not, AFAIK, compiled with c++11 flag.
If you are really that interested in newest c++, then my clang recommendation is probably not good. GCC 4.7 has a pretty decent support for C++11 stuff already, 4.8 improves that further, but there are some "performance problems":http://www.phoronix.com/scan.php?page=news_item&px=MTI5ODE (may be resolved in the future, since it's still not released).
I've looked at some more tests now and it seems that only linker optimisations are slower - remaining compiler stuff is in fact faster than in GCC 4.7. So maybe my concerns are not valid here, either ;)
-
One thought occurs to me, as long as we can target x86 first, are there cross compilers that convert that instruction set to ARM5? Something like that might work instead of taking a direct compiler from source code to ARM5 architecture. Again, don't know the tool sets or tool chains available to facilitate something like that, per se.
-
I do not think it is save to assume that a compiler that produces working code for intel machines will also produce working code for ARM. If you want to target ARM, then evaluate your compiler with that specific ARM CPU. Everything else is going to lead to nasty surprises later.