gcc 4.8 and ubuntu 12.04

[trantran]

I am trying to have a C++11 compiler that works.
It seems (if the publicity is right... and typically it never usually is!) that gnu g++ 4.8 might be it.

So I installed Ubuntu 12.04 read the instruction on multiple sites, did EXACTLY as it was said, got (obviously) errors, repeated again, got the same result, tried different ways, etc.

Typically I get completely cryptic errors such as:: error 4 or error 2 WITHOUT any sort of error log available nor information to consult (this is very very typical of my experience with gnu).

This is extraordinarily frustrating.
How does the community cope with this? Are you all saints and fabulously resilient to continue working in those conditions?

So I ask: has anybody ever succeeded in building/loading/using SUCCESSFULLY g++ 4.8 on a Ubuntu computer?

Then in what mysterious ways have you been able to achieve this monumental achievement?

[trantran]

...

[mike_2000_17]

So I ask: has anybody ever succeeded in building/loading/using SUCCESSFULLY g++ 4.8 on a Ubuntu computer?

Yes. I keep a rolling version of GCC on my computer at all times, i.e., GCC compiled from source obtained from the latest development branch of GCC's svn repository. And most of my computers have Ubuntu (actually Kubuntu, but it doesn't make a difference for this task). I also have a fedora laptop, and I also have a rolling version of GCC there too. No problem.

Then in what mysterious ways have you been able to achieve this monumental achievement?

I wouldn't call it a "monumental achievement". Except for the time that it takes to compile all the code-base (a couple of hours), I never had too much trouble doing it. I followed the instructions carefully, made sure to install all the dependencies, and that's it. I remember getting a few errors, but I just copied the error message, googled for it, and found a fix within a very short time.

Do you have a specific problem?

Typically I get completely cryptic errors such as:: error 4 or error 2 WITHOUT any sort of error log available nor information to consult (this is very very typical of my experience with gnu).

Most of the time, if there are errors (which might be cryptic to you), they only show up on the terminal at a high-level, the error logs are located within the sub-directories of your build directory, they end with a .log extension, and that's where you'll find the specific info on the error. In general, the errors are just due to a missing dependency.

[mike_2000_17]

And by the way, version 4.7.2 that is now on Ubuntu's repositories is perfectly fine for doing C++11 coding, the difference between 4.7.2 and 4.8.0 is not that great in that regard.

[trantran]

I followed the following script from a book claiming to follow the gnu instruction.

svn checkout svn:://gcc-gnu.org/svn/gcc/trunk gcc-trunk
mkdir gcc-build
cd gcc-build
../gcc-trunk/configure --enable-build-with-cxx --enable-languages=c,c++
make -j6
sudo make install

This does result in nothing but an error:

configure: error: in /home/installer/build/i686-pc-linux-gnu/64/libgomp': configure: error: C compiler cannot create executables Seeconfig.log' for more details.
make[1]: *** [configure-target-libgomp] Error 1
make[1]: Leaving directory `/home/installer/build'
make: *** [all] Error 2

[trantran]

Have you tried clang?

The best I can do is compile an empty main function.

If I add #include <iostream> in a reckless moment of happy expectation, it can't compile it and I can have real fun trying to decipher:

/tmp/test2-LUg9Sk.o: In function __cxx_global_var_init': test2.cpp:(.text+0x10): undefined reference tostd::ios_base::Init::Init()'
test2.cpp:(.text+0x16): undefined reference to `std::ios_base::Init::~Init()'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Never mind adding a nirvanic: cout << "hello world" << endl. You'd be dreaming in technicolor if you'd be expecting that to work.

But an empty main, yeah it will compile that just fine. Wow.

I am curious: were you able to configure linux to get anything done (more than an empty main function that is) by yourself or do you have a fully staffed department devoted to prepare the computers you are using and that you can rely on ?

For an individual like me, linux/gnu/clang/whatever it's months trying to make it work and absolutely, absolutely: 0 result.

I thought before Microsoft/Windows was by moment frustrating. That's because I hadn't tried Linux. Now I am starting to think that Windows is wonderful.

[mike_2000_17]

Have you tried clang?

It's funny you say that. I just built clang + llvm + libc++ from source today (for the first time). I had no problem whatsoever. And now, I'm compiling my entire code-base with it (about 130 thousand lines of code) and it's going very well. I also just tried a very nice utility derived from clang, called include-what-you-use to analyse header-file dependencies in the hopes of reducing inter-dependencies and adding forward-declarations wherever possible (getting this tool was the main reason that I compiled clang from source). Clang is a great compiler, it's very fast, standard compliant and uses very little memory.

If I add #include <iostream> in a reckless moment of happy expectation, it can't compile it and I can have real fun trying to decipher:

/tmp/test2-LUg9Sk.o: In function __cxx_global_var_init': test2.cpp:(.text+0x10): undefined reference tostd::ios_base::Init::Init()'
test2.cpp:(.text+0x16): undefined reference to `std::ios_base::Init::~Init()'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

It seems that your clang program is not able to find the standard library to link to. Clang can use either libstdc++ (from GCC) or libc++ (from LLVM project). You can specify it as a command-line argument (but it should attempt to look for libstdc++ by default):

$ clang -stdlib=libstdc++ test2.cpp -o test2

or

$ clang -stdlib=libc++ test2.cpp -o test2

You must make sure that either one or both of these are installed. The easiest is just to make sure you have installed the package build-essential. Normally, if either of these libraries are installed (from a repository), clang should have no trouble finding it.

I am curious: were you able to configure linux to get anything done (more than an empty main function that is) by yourself or do you have a fully staffed department devoted to prepare the computers you are using and that you can rely on ?

For an individual like me, linux/gnu/clang/whatever it's months trying to make it work and absolutely, absolutely: 0 result.

It's just me. I really don't understand why you have so much trouble. Everything has pretty much always worked right out of the box for me, on every linux box I have ever installed or used. You must have done something that wasn't very kosher with your system.

I followed the following script from a book claiming to follow the gnu instruction.

You should follow the official instructions.

configure: error: in /home/installer/build/i686-pc-linux-gnu/64/libgomp': configure: error: C compiler cannot create executables See 'config.log' for more details.

First, are you sure you have gcc installed? If not, installing build-essential should do the trick.

Second, that's not a cryptic error message, it tells you to look into config.log. It might be a good idea to look there for an error message.

Third, if you are using a 64bit system, there is a known configuration bug which makes the linker unable to find some basic libraries (crti.o, crt1.o, etc.). Normally, those would be in the folder /usr/lib/x86_64-linux-gnu/, but should be in /usr/lib64, and so, a simple fix is to create a symlink:

$ sudo ln -s /usr/lib/x86_64-linux-gnu /usr/lib64

It might not be x86_64-linux-gnu depending on your actual system. This is a recent change of Debian (the base for Ubuntu) for multi-architecture systems. To find the appropriate directory, just use this command:

$ locate crti.o

which should print out one or a few file paths, and one will look something like /usr/lib/something/ctri.o, and you that path (the /usr/lib/something) in the symlink command above.

[trantran]

Ok, now I actually seem to be able to compile Clang 3.3. The computer is running for quite some time now (I am crossing my fingers...). I am curious: about I long will it take on a duo-core laptop ? An hour or a day?
But still no chance with building Gcc. Since I have gcc 4.7.2 installed through ubuntu and since this is very compliant that is quite satisfactory. But still, why is it not working (the config.log that it refers is many many pages long and totally useless for me)?
Maybe I just messed earlier the system beyond repair while trying everything and just need to reinstall everything all over and lose another week time reinstalling. So typical with linux (at least that has been my experience)

[mike_2000_17]

Ok, now I actually seem to be able to compile Clang 3.3. The computer is running for quite some time now (I am crossing my fingers...). I am curious: about I long will it take on a duo-core laptop ? An hour or a day?

It should take about an hour, at most two. Clang and LLVM are not that big.

But still, why is it not working (the config.log that it refers is many many pages long and totally useless for me)?

I'm pretty sure it is this issue with the crti.o libraries and such (as in my previous post). I had that issue before, and it is seems to be a recent change by Debian (since Ubuntu 11.10) that the GNU people didn't adjust to yet in their configuration scripts.

[trantran]

Ok, completed compilation of Clang 3.3
In other system, you wouldn't need to do this: you would just use the working binaries that you be available at the site of the developper. But, hey this is the linux world: always make it the most complicated possible so we can keep busy all the time.

Note: no error message. Compilation supposedly ok. clang -v return 3.3. So everything should be well. Except for one thing: this is linux world. That would be way too simple.

So here is the output of this sophisticated (for linux compilers that is) code:

//                #include <iostream>
//              using namespace std;
 //              int main (int argc, char * argv[]){
   //                       cout << "hello clang" << endl;
     //           }

RESULT:

 //        /usr/lib/gcc/i686-linux-gnu/4.7/../../../../include/c++/4.7/iostream:38:10: //           fatal error: 
//                    'bits/c++config.h' file not found
//        #include <bits/c++config.h>
//                  ^
 //   1 error generated.

Great. We can now continue to work all night long. I can anticipate what's wrong: this library not compatible with that, and that one obsolete, and this one buggy replaced by that other which is itself not compatible with the first one. See, I have learn Linux quite well: now I can anticipate what is wrong and how long it will take to fix it.

Linux is really for people who don't have anything to do in life and love it because it keeps them busy all the time.

What about Apple?
Have you tried them? For general use everybody say it's very user-friendly.
Is it the same for their programming environment. Do they have a very-compliant C++ that actually works out of the box?

Do we have a sort of hierarchy like:
Apple: super easy. You can actually write some useful code.
Window: intermediate
Linux: you have to reinvent the wheel all the time, try to make your tool forever and have no time to actualy write any code.

Or is Apple not very good?

[mike_2000_17]

Ok, completed compilation of Clang 3.3
In other system, you wouldn't need to do this: you would just use the working binaries that you be available at the site of the developper. But, hey this is the linux world: always make it the most complicated possible so we can keep busy all the time.

Take any fairly complex bleeding-edge open-source library or application and try to use it in any system other than Linux, and then you will know what real pain is. You cannot compare something like getting the very latest version of Clang or GCC (a very recent, experimental-version, open-source compiler) with something like installing stable versions of GCC or MSVC distributed in Windows. MSVC works on a 2 to 3 year release cycle (which is really long), is closed-source, and commercially packaged. GCC has a much shorter release cycle on Unix-like systems (a few months), is open-source, and is packaged (as binaries) only after sufficient stability and field-testing, and is packaged for Windows (in MinGW) every so often (and never with the bleeding-edge version either). If you can accept that situation (lagging behind in version, waiting on long release cycles), as the vast majority of people can, then you can install those pre-packaged binaries and have no trouble at all, in Linux, it is as easy as issuing the command $ sudo apt-get install build-essential and that's it. But if you choose to get the bleeding-edge version (of Clang or GCC), you must accept that there will be some efforts required of you to get it to work and you have to accept that there might be a few bugs / instabilities, but overall it is relatively painless (having to tweek a few configurations in order to be able to get several hundreds of thousands of lines of code to compile successful on a brand new system is a miracle). In Windows, trying to do the same thing would be suicidal unless you are part of the development team, but as an individual, you have no choice but to wait for binary packages to be rolled out (every year or so for MinGW-GCC, and every 2-3 years for MSVC). You are comparing apples and oranges.

So here is the output of this sophisticated (for linux compilers that is) code:

...

Great. We can now continue to work all night long.

You must have seriously tempered with your system for that code to fail. I frankly think you are just reaping what you sowed. Whatever you did to your system, it's your mess to fix. Don't blaim the car salesman after you took a jack-hammer to the hood of your new car.

What about Apple?
Have you tried them? For general use everybody say it's very user-friendly.
Is it the same for their programming environment. Do they have a very-compliant C++ that actually works out of the box?

Mac OSX is a Unix-like environment. It is almost identical in every meaningful way to Linux when it comes to system structure and overall development environment. The only problem is that you cannot easily install GCC binaries because Apple prefers Clang (and Apple is largely responsible for creating and developing Clang in the first place). And even then, the Clang version (binary package) that can be easily installed in Apple is an older version (I think 2.9 or 3.0). But, because the environment is Unix-like, it is much easier (as easy as in Linux) to get a bleeding-edge compiler compiled from source. So, Apple is a pretty good development environment, mostly owing to the fact that Apple has adopted the Unix system architecture, like every other OS in existence today except for Windows. Of course, Linux distributions are still much better than Apple for development, especially in C++, mostly because of wide availability of a vast amount of libraries and development tools, so that you never have to re-invent the wheel. Most operating systems have adopted the long-standing and extremely robust system architecture that was first established with Unix, and for good reason.

Do we have a sort of hierarchy like:
Apple: super easy. You can actually write some useful code.
Window: intermediate
Linux: you have to reinvent the wheel all the time, try to make your tool forever and have no time to actualy write any code.

More like this:
Linux/Unix: full power of the unix tool-chains, vast amount of bleeding-edge libraries, and a powerful shell and integrated scripting languages, and host to by far the greatest amount of performance-critical and professional software.
Apple: basic sub-set of the unix tool-chains, decent development tools, not so terrible to work with.
Windows: some good commercial tool-chains on long release cycles, no wide-spread or reliable system standards or API, a terrible architecture, security issues, poor community support.... the list goes on... just a bad development environment and lots of time wasted on it.

That has just been my experience (only close to 15 years, so I'm still a rookie), but I'm certainly not alone. It's only when you are used to using a unix-like environment that you realize how much time is wasted when trying to do anything under Windows. I can easily have to spend a few days to do what I can do within 30min or an hour in Linux, the two systems don't even compare. Try compiling GCC 4.8 under Windows 8, and tell me how that goes, you'd probably have to work at it full-time for weeks to get it to work (believe me, I've tried similar things in the past), yet, I'm sure even a novice like you could get GCC to compile with just a little bit more effort. That's a very typical ratio.

If you think that the troubles you've had getting GCC to compile is a lot, then you clearly haven't been around for long. You are scared of trivial errors and of looking through log files, or of taking any kind of steps to trace it back to its source, and you call those hurdles "the most complicated possible". Either you're joking, or you're just too blind to see that it's your own laziness and incompetence that you're frustrated about.

[trantran]

gcc --version
gcc (GCC) 4.8.0 20130127 (experimental)
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Done!

Now amazingly, that installation FIXED automatically my clang compiler without any other measure from my part!

And my clang 3.3 compiler can now compile without error a program that output a complex "hello clang" output.

How did I do it?

"You are scared of trivial errors and of looking through log files, or of taking any kind of steps to trace it back to its source"

Well it's not that I am scared of it, it's that gnu itself say to ignore those errors in the log and that they say they are typically normal. Furthermore, the config.log (the only log that was available after the failed make anywhere in the directory trees) last line was exit with status 0 and that was what prompted me to ignore it and consider only the undecipherable make error=1 error=2 as being relevant. So there is nothing a normal user could do about it. You can't deny that.

So how did I solved the problem ???

I emailed the authors of the svn installation scripted who replied within hours. They looked at the config.log (that had exited with 0, mind you...) and figured that I had probably not installed bison and yacc and suggested a script to fix this and clean the system. I don't know for sure what in their script in effect worked, but it did.

So now it works.
Even the thread library is recognized and appear to work in very simple example!

Thanks for the encouragement, but it will take a few days or weeks to digest my frustrations.

But I have to give you right on 2 things:
- fact 1 is that I can't have a thoroughly compliant vs c++11 compiler in window now, and that I can have one now in linux. So: linux 1 windows 0 on this.
- fact 2: it is true that the linux community support is good (it needs to be, otherwise it would be impossible to program at all)