I recently installed gcc 4.8.2 and boost 1.55.0 on CentOS 6.4 to take advantage of the improved support for C++-11. It was painful to do manually so I automated the process with this script: http://projects.joelinoff.com/gcc-4.8.2/bld.sh. Hopefully this will make it easier for folks that want to experiment with the latest version of the GNU C++ compiler.
There is also a very simple Makefile: http://projects.joelinoff.com/gcc-4.8.2/Makefile that is not required but that I found useful.
This text version is also available so that you can cut-n-paste from a web page: http://projects.joelinoff.com/gcc-4.8.2/bld.sh.txt.
Please note that this is not a product. It is simply my best attempt to get it working in my development environments. For example, it does not check for packages because I try to build it on different systems that have different package managers (yum, apt, port, etc.). What this means is that if it doesn’t work for you, you will have to do some debugging. If you find a problem, please post a fix in the comment section here so that others can benefit from it.
1 Download and Install It
Here are the steps to download and install it. Root access is not required unless you need to install support packages.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
$ # Download and install it. $ mkdir /shared/tools/gcc/4.8.2 $ cd /shared/tools/gcc/4.8.2 $ wget http://projects.joelinoff.com/gcc-4.8.2/bld.sh $ chmod a+x bld.sh $ # Optionally there is also a very simple Makefile. $ wget http://projects.joelinoff.com/gcc-4.8.2/Makefile $ # bld.sh doesn't check for packages $ # This is one that I needed. $ # if not installed you will see a missing gnu/stabs-32.h error late in the process. $ sudo yum install -y glibc-devel.i686 <output snipped> $ # I also had to install texinfo, you may have to install others. $ sudo yum install -y texinfo <output snipped> $ # You can run bld.sh directly or you can simply type "make" if you downloaded $ # the Makefile. $ ./bld.sh 2>&1| tee bld.log |
The build process can take a long time depending on the speed of your CPU(s) and disks. On my test system it took more than 5 hours.
If the process fails it is most likely because packages are missing on the system.
If a problem does occur, install the package, then delete the src and bld directories and try again. If you have installed the option Makefile you can type “make clean” and then “make”.
The rtf (release to field) directory contains the releases for each package.
2 How to Use the Compiler
This section shows how to compile, link and execute a simple program using the newly installed compiler by setting up your environment properly.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
// Simple test program #include <iostream> #include <boost/algorithm/string.hpp> using namespace std; using namespace boost; int main() { string s1(" hello world! "); cout << "value : '" << s1 << "'" <<endl; to_upper(s1); cout << "to_upper() : '" << s1 << "'" <<endl; trim(s1); cout << "trim() : '" << s1 << "'" <<endl; return 0; } |
You compile, link and run it as follows:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
#!/bin/bash # This script sets the environment to use the newly installed compiler. # It compiles, links and runs a small test program. # Setup the environment. MY_GXX_HOME="/shared/tools/gcc/4.8.2/rtf" export PATH="${MY_GXX_HOME}/bin:${PATH}" export LD_LIBRARY_PATH="${MY_GXX_HOME}/lib:${MY_GXX_HOME}/lib64:${LD_LIBRARY_PATH}" export LD_RUN_PATH="${MY_GXX_HOME}/lib:${MY_GXX_HOME}/lib64:${LD_LIBRARY_PATH}" # Compile and link. g++ -O3 -std=c++11 -Wall -o test.exe test.cc # Run. ./test.exe # Expected output # value : ' hello world! ' # to_upper() : ' HELLO WORLD! ' # trim() : 'HELLO WORLD!' |
3 Disk Space Requirements
You will need about 4GB to download and build all of the packages. Once the build is finished you can reclaim most of the space because the released files only require about 500 MB. Here is the breakdown:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
$ cd /shared/tools $ du -s -h gcc/4.8.2 3.2G gcc/4.8.2 $ du -s -h gcc/4.8.2/* 185M gcc/4.8.2/archives 1.7G gcc/4.8.2/bld 13K gcc/4.8.2/bld.sh 9.8M gcc/4.8.2/logs 1.5K gcc/4.8.2/Makefile 412M gcc/4.8.2/rtf 881M gcc/4.8.2/src |
Note that the logs directory exists because I used the “make” command instead of running blds.sh directly.
Once it is built you can remove everything except the contents of the rtf directory tree to save disk space.
4 Packages
This is the list of packages that are installed in the release area.
| Package | Version | Web Site |
|---|---|---|
| binutils |
2.24
|
http://ftp.gnu.org/gnu/binutils |
| boost |
1.55.0
|
http://sourceforge.net/projects/boost/files/boost |
| cloog |
0.18.0
|
http://www.bastoul.net/cloog”>http://www.bastoul.net/cloog |
| gcc |
4.8.2
|
http://ftp.gnu.org/gnu/gcc |
| gmp |
5.1.3
|
http://gmplib.org/ |
| libiconv |
1.14
|
http://ftp.gnu.org/pub/gnu/libiconv |
| mpc |
1.0.2
|
http://www.multiprecision.org/mpc |
| mpfr |
3.1.2
|
http://www.mpfr.org |
| ppl |
1.1
|
http://bugseng.com/products/ppl |
5 Tested Platforms
These are the platforms that I actually tested the installation on.
| Distro | Version | Arch | Status | Notes |
|---|---|---|---|---|
| CentOS |
5.5
|
x86_64 | Passed | As of 2014-03-25. |
| CentOS |
6.4
|
x86_64 | Passed | Had to manually install the glibc_devel.i686 and texinfo packages. |
| MAC OS X (Maverick) |
10.9
|
x86_64 | Passed | As of 2014-03-25. |
| Scientific Linux |
6.5
|
x86_64 | Passed | As of 2014-04-01 by Fred S. |
Unfortunately, I do not have the bandwidth to try to get this to work on other distros (even though I have several Ubuntu boxes at hand) but it should be fairly straightforward to port because it does not rely on distro specific package management.
If you port it to another distro, please send me the changes to that I can incorporate them.
Enjoy!
First i would like to say thanks a lot you saved me a lot of time !
Just a small tip … the make should be -j in bld.sh cpu count so it will run faster.
Thank you, enabling parallel processing is an excellent suggestion.
Hi, i’m try to use your script on CentOS 6.4 x86_64 and get this log http://pastebin.com/69Y1R5W8. How I can fix that?
Hi,
It looks like your installation was killed while gmp was being built or that there was a problem with the gmp download. My guess is that the build failed somehow.
If that is what happened there there were entries in the src and bld directories that left the script thinking that gmp had built successfully.
The best way to fix it is to remove the bld, src and rtf directories and try again. Trying to pick out the individual elements can be time consuming and error prone. That is certainly an area where the script could be enhanced.
Please keep a log of the first run (the one that tries to build gmp) so we can track down what went wrong there. It is possible that you have a missing package. Also, make sure that you have sufficient disk space.
Cheers,
Joe
thx, i’ll try agan. also, MPFR is 3.1.2 and link to 3.1.1 not working
This is fabulous, countless hours not wasted.
Thanks a lot.
Thanks for great work! Small remark: boost version in the bld.sh is 1.51, not 1.54. Seems not update from previous article “gcc 4.72 & boost 1.51”.
Cheers,
Alex
I just verified that boost 1.54 is referenced at line 316 by downloading these two files:
Are you sure that you downloaded the correct script? If so, can you tell me which URL you used?
It looks like there was a bad link at the top of the page that was linking to 2.7.2. It has been fixed, sorry about that.
Looks like mpfr-3.1.1.tar.bz2 is no longer available at http://www.mpfr.org/mpfr-current/#download but 3.1.2 is. I changed the script not sure if it works yet.
Thanks for letting me know. If you find that it works, please let me know and I will update the script. If it doesn’t work, I will dig in.
Looks like it compiled with zero errors with mpfr 3.1.2. All is good.
Thanks much for taking the time to do this!
Thanks for doing the verification. The problem was with the old script (4.7.2) and the invalid link that you pointed out. Fortunately the new script has the correct version of mpfr.
I appreciate your help in tracking this down. I’ll bet that it caused problems for other folks as well.
Oops… just noticed the link at the top of this page says it’s for 4.8.2 but it’s for 4.7.2 as someone else mentioned.
It points to: gcc-4.7.2/bld.sh
Thanks for pointing that out. I have fixed it. Sorry about that.
Updated on 2014-02-11 to add support for boost-1.55. Also updated some of the support packages.
This weekend I verified that this tool also works on CentOS 6.5.
Thank you very much! It saves me lots of time.
I successfully used your script to install them on my CentOS 6.5.
During installation, I fixed some problems as follows. (Hope this can help other people)
1. As you said, install glibc-devel.i686 and textinfo
2. install bison
3. fix problem about libstdc++.so when installing ppl-1.1 (seems that it reads a 32-bit file on a 64-bit OS, the error message is “could not read symbols: File in wrong format”)
Thank you again!
Thank you for providing the additional hints.
Everything installed successfully, thank you very much for posting this. However, once I attempt to use the new gcc version on an old project (compiled successfully under gcc 4.4), I get the following errors: http://pastebin.com/ERrmLSEA. Seems like internal boost errors, not sure if it has to do with the fact that I already had boost installed and then maybe your script installed a different version of boost on top of it or something? I will keep trying to debug but wasn’t sure if you had any thoughts/ideas?
It looks like your compilation is picking up the wrong version of Boost. Have you set you LD_LIBRARY_PATH and include paths to pick up your new installation? There should be examples in the src/LOCAL-TEST directory.
I was wrong in my comment above, you should not have to specify the include paths but you will probably have to update LD_LIBRARY_PATH. How were you running the newly installed compiler? I did not see that in the pastebin output.
Seems as if the boost 1.55 libraries didnt download and its using the old version still. In the install log, it says:
Does this mean that it skipped installing boost? Additionally, i dont see anything in the rtf directory about boost or many of the other packages you say are installed in the release directory in step 4; it just seems like the tar files were downloaded into the archive folder but nothing else happened with them. Any idea why that might have happened in the install?
The message only indicates that the boost archive was found in the archives directory. It does not indicate whether it was installed. There will be other messages for that.
If the boost build failed for some reason you will need to verify that the boost archive in the archives directory is correct either by determining whether the check sum and block count are correct using “sum”. The correct values are “24814 56784 boost_1_55_0.tar.bz2” or by removing it from the archives directory and running again.
I normally just delete the boost entries from archives/ src/boost* and bld/boost* and then restart the script (or make) when this sort of thing happens.
I ran it through a makefile. It turned out that the errors had to do with an existing version of boost existing on the machine already that I didn’t know about. Sorry about that.
After looking through more of the log file, it looks like boost compiled and installed successfully, it just compiled into the src/boost_1_55/stage/lib directory.
Hi
Using Scientific Linux 6.5
# cat /etc/redhat-release
Scientific Linux release 6.5 (Carbon)
Everything looks fine but then when the script starts running some tests I get:
…
# ================================================================
# Archive: LOCAL
# PWD: /opt/tools/gcc/4.8.2/src/LOCAL-TEST
# CMD: TEST 8 ./test1.dbg
# ================================================================
IO works
STATUS = 0
# ================================================================
# Archive: LOCAL
# PWD: /opt/tools/gcc/4.8.2/src/LOCAL-TEST
# CMD: TEST 9 g++ -O3 -Wall -o test2.bin test2.cc
# ================================================================
test2.cc:2:38: fatal error: boost/algorithm/string.hpp: No such file or directory
#include <boost/algorithm/string.hpp>
^
compilation terminated.
STATUS = 1
Any idea?
Thanks
Fred
Is it possible that boost was not correctly installed? Search your log file for “Step : BUILD” where the file is “boost_1_55_0.tar.bz2” and see whether there is an error reported. On some systems there may be a bash error that is causing boost not to build. If you see a problem, let me know and I will try to fix it as quickly as possible.
I think that I found a problem in bld.sh script that was causing a syntax error. There was also a problem setting LD_LIBRARY_PATH properly for 64 bit hosts. I have updated bld.sh (and build.sh.txt). Go ahead and download it and try again. Make sure that the date value in the script is:
# Date: 2014-04-25
With the fixes above I was also able to install gcc-4.8.2/boost-1.55 on CentOS 5.5.
There was a bug in the version of the script that I uploaded yesterday that will cause it to fail during the boost installation. I have fixed it and have updated the script version to 2014-03-26.
Posted an updated version of bld.sh today that works on CentOS 5.5 and Mac OS X 10.9.
Updated the compile/link example to show the use of LD_RUN_PATH so that your executable will pick up the correct libraries at run time, added the lib64 references so that it will work on 64 bit platforms and added the -std=c++11 compile option to enable C++-11 features.
Hi
I have (re-)downloaded the bld.sh script and Makefile yesterday (31MAR2014) and it works now all the way on Scientific Linux 6.5 (x86_64)
Note the (weird) date in the bld.sh script:
#!/bin/bash
#
# Date: 2014-04-26
#
# This downloads, builds and installs the gcc-4.8.2 compiler and boost
# 1.55. It handles the dependent packages like gmp-5.1.3, mpfr-3.1.2,
# mpc-1.0.2, ppl-1.1, cloog-0.18.0 and binutils-2.24.
…
Thanks for fixing the script. Very much appreciated.
Fred
You are welcome. I glad to hear that it is working now.
Thanks for pointing out the strange date. It should have been 2014-03-26. I have changed it.
I have also added Scientific Linux to the list of successful builds. Thanks for trying it out.
Joe,
while I’m writing, I’m givin’ your script a first try. ..
From my experience, it’s very important to run and confirm all the self-tests of the tools that are involved. “Hello World” is of course not a real test when it comes to judge the trustiness of GCC. In my past I’ve never had any trouble to build the GCC but to run its test environment (make -k check) without any violation.
How do you handle this for yourself? Isn’t it important to your application of GCC?
Respect for the work you’ve accomplished so far.
Best regards, Yves
Running all of the self-tests is a great idea. I do that for production work as well. You can modify the script to do that by adding “make test” or “make check”. I do not do that by default because it really slows things down for running experiments.
Note that before considering the experimental compiler for production, I build and test a complete system that is >10M LOC.
For the next release I will add an option that allows you to enable that functionality.
Joe, thank you for this awesome tool which I just ran on Centos 6.4 successfully.
I had to install the following packages first: flex, bison, texinfo, glibc-devel.i686
The output ended up in the directory /root. So I modified the build script to say
MY_GXX_HOME=”/root/rtf”
On my Lenovo W510 with 16GB memory, with Centos in a VMWare player session the whole script took 3 hours to run.
I am glad to hear it worked. Modifying the script to install in /root/rtf is perfectly fine but the script will install the compiler in the current directory by default. Here is what I typically do:
$ mkdir /opt/gcc/4.8.2/test1
$ cd /opt/gcc/4.8.2/test1
$ wget http://projects.joelinoff.com/gcc-4.8.2/bld.sh
$ wget http://projects.joelinoff.com/gcc-4.8.2/Makefile
$ make
Hello I am trying to install gcc 4.8.2 in CentOS 6.5, and I also met the same problem you mentioned above, it lacks glibc_devel.i686 and texinfo packages.
Error message in config.log while “make” gcc:
g++: unrecognized option ‘-static-libstdc++’
conftest.cpp:11:2: error: #error -static-libstdc++ not implemented
Unfortunately, I have no root permission so that I cannot use yum to install these packages, so what should I do? Thanks!
I don’t know how to install CentOS 6.5 packages as a non-privileged user or whether it is even possible.
I am a bit confused by the second part of your question. It sounds like you assumed that glibc_devel was not installed because the unrecognized option (-static-libstdc++) statement. That may or may not indicate that the package is missing.
To determine whether a missing package is the culprit, run a command like: “yum list | grep -i glibc_devel”. If the package is not there then that is the source your problem (as you surmised) but it is also possible to see the bad -static-libstdc++ reference if the build failed and was restarted without removing the src, bld and rtf directories from the package that failed.
If you have determined that there are packages missing then my suggestion is to work with your system administrators to get them installed.
If that is not possible then create a CentOS 6.5 virtual machine where you have root privileges using whatever technology is available to you (VirtualBox, VMWare Player, Xen, KVM, proxmox, etc.) and build the compiler there (/home//work/gcc/4.82). You can then copy over the rtf directory to the same location on your regular host (/home/ /work/gcc/4.8.2) to continue testing.
If the glibc_devel package is not missing, then try removing the src, rtf and bld directories, and running bld.sh (or make) again.
Hi,
Thanks for proving the script,
It was dong well, till it got down to building binutils-2.24 and failed as follows.
Appreciate any pointers to get past this, I am building this on an x86_64 box running RHEL 6.5:
/root/tmp/gcc-4.8.2/src/binutils-2.24/gold/script-c.h:221:7: warning: ‘yylex’ initialized and declared ‘extern’ [enabled by default]
yylex(YYSTYPE*, void* closure);
^
/root/tmp/gcc-4.8.2/src/binutils-2.24/gold/script-c.h:221:7: error: ‘YYSTYPE’ was not declared in this scope
/root/tmp/gcc-4.8.2/src/binutils-2.24/gold/script-c.h:221:15: error: expected primary-expression before ‘,’ token
yylex(YYSTYPE*, void* closure);
^
/root/tmp/gcc-4.8.2/src/binutils-2.24/gold/script-c.h:221:17: error: expected primary-expression before ‘void’
yylex(YYSTYPE*, void* closure);
^
/root/tmp/gcc-4.8.2/src/binutils-2.24/gold/script-c.h:221:30: error: expression list treated as compound expression in initializer [-fpermissive]
yylex(YYSTYPE*, void* closure);
^
make[4]: *** [expression.o] Error 1
make[4]: Leaving directory
/root/tmp/gcc-4.8.2/bld/binutils-2.24/gold'/root/tmp/gcc-4.8.2/bld/binutils-2.24/gold’make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
make[2]: *** [all] Error 2
make[2]: Leaving directory
/root/tmp/gcc-4.8.2/bld/binutils-2.24/gold'/root/tmp/gcc-4.8.2/bld/binutils-2.24′make[1]: *** [all-gold] Error 2
make[1]: Leaving directory
make: *** [all] Error 2
I am not sure what is going here but my guess is that you are missing one or more packages.
The first hint is that YYSTYPE is not defined. It should have been generated in the y.tab.c file (or equivalent) by yacc. Do you have yacc or byacc installed? Do you have lex or flex installed? If those tools are not installed you might see the failure you described. If that is the case, install the packages, remove the src/binutils* and bld/binutils* directories and rebuild.
thanks, I test it on Centos6.5, it also works.
Thanks for a marvelous posting! I seriously enjoyed reading it, you could be
a great author. I will be sure to bookmark your blog and will eventually come
back very soon. I want to encourage that you continue your great work, have
a nice evening!
Thanks for your scripts. It helps me to gain a lot of knowledge of Linux/Centos installtions and commands. I asked you questions earlier that I did not pass the TEST 13. And I thanks you for your kindly reply. Although I still can not pass the TEST 13, I might have more information that you might be able to help me out.
1. I did not install the packages as “su”
2. Since my Centos 6.5 has boost 1.41.0-18.el6, I left the boost 1.55 out from your scripts.
3. I did modify your scripts because my Centos does not have internet connection. I pre-download all the packages you have mentioned and put into archive directory before running installation.
4. My whole purpose to install gcc4.8.x is that I wanted to install Qt5.2.x. My Centos6.5 has 4.4.X that version is not high enough for Qt5.2.x. After running your scripts, I think that the gcc4.8 is installed. But, because I has the “PATH” problem, I copied the libstdc++.so.6.0.18 into /usr/lib64 directory and made a new link to this libstdc++.so.6.0.18 to trick the Qt5.2.1 to install. It worked. Then, I checked the gcc version from Qt5.2.1. Qt says:
Qt Creator 3.0.1
Based on Qt 5.2.1 (GCC 4.6.1 64 bit)
Is the GCC 4.6.1 the real version or just the libstdc++.so ?
If the GCC 4.6.1 is the version I actually installed, is it able to run -std=c++11 command?
Thanks again!
I am not sure that I can help since I don’t work with Qt but here some thoughts.
You do not need to install the packages as su so that is not an issue.
I would strongly recommend not modifying the script and leaving Boost 1.55 in but that is your choice. Boost 1.41 is pretty old (like gcc-4.6.1) and the newer versions can take advantage of C++-11/14 constructs to improve performance.
The script does not need to be modified for the internet access. If the packages are found in the archives directory, it will use them. I use this technique all of the time for testing.
I also would not recommend copying any files from the gcc-4.8.x distribution into your production paths because it could destabilize your system. A better approach would be produce a run script that setup your LD_LIBRARY_PATH and PATH environment variables appropriately for running your newer version of Qt.
Another option would be to consider a distribution that has more up to date versions of the compiler and Qt. One possibility might be Fedora, another might be Ubuntu.
Thanks a lot. I have a great news, I have successfully installed gcc4.9.0 with boost1.55 into another Centos6.5 machine. Now the std=c++11 runs without errors. During the installation, I did have one failure due to the Centos is setup as 64 bit machine only. Your scripts is intelligent, it actually told me to disable the multilib, and I did. Then the installations went smoothly.
My last questions:
1. I am not sure what you meant: “a run script”? Are they like what you suggested earlier: export PATH=/home/me/mygcc/rtf/bin:$PATH and export LD_LIBRARY_PATH=/home/me/mygcc/rtf/lib:$LD_LIBRARY_PATH
2. Are these environment variables setting permanent so that the every user of the machine could be able to use it? And the system will remember them after rebooting?
3. As far as I knew, the Qt5.X are only looking for /usr/lib64/libstdc++.so.6 during installation. After Qt is installed, I could configure Qt to use new environment. So, will it be possible I just “replace” the gcc 4.8 and boost 1.55 in the “production” during installation of gcc and boost? I am going to re-do the installations for my machine. I just wonder I could do differently to set the things I need at the frist place.
I could not tell you how much I appreciate your helps. And, your installation scripts, nothing is better than that.
I am trying to install the gcc into a virtual machine (Centos 6.5) this time. I am using the same bld.sh as I had successfully installed two stand alone machines before. Now, I run into a strange problem:
/usr/bin/ld: crt1.o: No such file: No such file or directory
collect2: ld returned 1 exit status
Configure error: I suspect your system does not have 32-bit development libraries (libc and headers). If you have them, rerun configure with –enable-multilib. If you do not have them, and you want to build a 64-bit-only compiler, rerun configure with –disable-multilib
I am not sure where is the place I could disable this multilib? Or does this crt1.o error have anything to do with multilib?
Thanks.