GNU C/C++14 Installation & Codeblocks 16.01 from Source (Command Line)

In yesterdays post I explained a C++14 user was having instant issues with the vanilla install of gcc/g++ on Ubuntu 14.04 LTS.

Getting a C++14 Compiler
So, here today are my command-line steps to update the GNU Toolchain v5.x.

sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-5 g++-5

If you already have compiler alternatives you may need these lines.

sudo update-alternatives
sudo update-alternatives --remove-all gcc
sudo update-alternatives --remove-all g++

But, everyone will need to swap the default gcc and g++ command-lines to the new paths to make them the defaults.

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-5 20
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-5 20
sudo update-alternatives --config gcc
sudo update-alternatives --config g++

These last two --config commands are only needed if you have multiple alterantives, so don't worry if it tells you it's failed as you only have the one.

Now, if you perform g++ --version, you should see it's a version 5.x series compiler.

Codeblocks 16.01
Older versions of Codeblocks may start to error on the code completion with some of the C++14 specific commands.  So, we need install some prerequisites, and then build the latest 16.01 version from source.

sudo apt-get instal gtk+-2.0 automake libtool libwxgtk2.8-dev libwxbase2.8-dev

wget http://sourceforge.net/projects/codeblocks/files/Sources/16.01/codeblocks_16.01.tar.gz

tar -xvf codeblocks_16.01.tar.gz

cd code*

The next step is interesting, we need to iteratively check:

./bootstrap

Running this will show you anything wrong with your machine environment, any missing dependences etc... However, once bootstrap runs cleanly, you can continue below.

./configure
make
sudo make install

The make step takes quite a time, the more cores & RAM you have the better, on an 4 core (8 thread) machine with 8 GB of ram, I've found it takes about 10 minutes.  On a single core machine as the poor VM I had was assigned, it took a lllooooottttt longer.

Once complete we needed to use the text editor of our choice, in sudo mode....

sudo nano /etc/ld.so.conf

And to this we need to add the line:

include /usr/local/lib

Save the file, exit the editor and run:

sudo ldconfig

Once this was complete, we can run up Codeblocks, and see it's version 16.01.

And we can further see the nice new C++14 options in the build options:

Even the code highlighting recognises the make_shared operation:

Voila, if this helped, do check out my other posts, and code, leave a tip with my new tip jar!  And I'll be making a video of this one soon, as it's so useful.

Clean PC & OpenGL

Its been a long weekend, and a hard weekend, I've been doing a lot of code over the weekend, moving an important project from a most defiantly developmental footing to a much more mature footing.

But I've also been and finally had the car sorted, the clutch was never right after the last fixes it had, I've had a new clutch fitted, then was told to fit a new clutch cable, which I did; but still the drive was not right.  When I went to pick the car up a very sheepish mechanic said "Its only £30 for a new pressure plate and oil".. okay... Cool... Two days of labour, £30... What gives... Yes, it'd had a whole other new clutch...

It drives sweet as a nut now, but it does make me wonder how crap was the other clutch, it lasted from October 2013 to June 2014.  I mean, I know after market clutches are cheap tack, but this took the Michael it really did.

Anyway, that all done I was wired late last night, so decided with the project above delivered for feedback I could take some time to service my main PC.  It had been a little battered over time... 

You can see the basic chassis here: http://megalomaniacbore.blogspot.co.uk/search?q=Silent+Fans

And the first thing I did was give the whole brushed aluminium case a good clean, the fins at the top the grills on the front and the dust mesh points at the bottom over the air in takes.

Then I opened it up and cleaned the case fans, now as you can see I fitted them in 2011, so that's just shy of 3 years service.  They were dusty, but not terribly so.  A quick wipe was all they needed, the rear of the case also just a quick wipe.

The most dust was concentrated in the graphics card, and around the CoolMaster plastic funnel which has its own mesh dust cover, this was sodden with dust and I soon had the card out and dusted it clean before refitting.

My other task was to clean the Corsair Airflow...

http://megalomaniacbore.blogspot.co.uk/2014/04/corsair-airflow-ram-cooler-getting-old.html

Now, this thing had been making a lot of noise, and when I disconnected it and brought it out into the mid-night light bulb glow it was utterly ditched.  Large foamy dust bunnies had formed on all the stanchions and as the whole machine is side mounted the upper sides of the support legs were thick with fir...

Really strange, considering that this is not the main cooler and that there's filtered grills all around this unit... But then it dawned on me, I connect this to the power fan header on the motherboard, and the Q-Fan profile does not include that header.  So this is the only fan set in the machine NOT being speed controlled against performance/heat.  So it was going to be noisy because of the small size of the fans.

Adding in the dust only added to the noise/turbulence.

Cleaned up and refitted tightly however and it is a lot quieter.  My Ram of course is also now being cooled better.

One other thing I'm taking a look at is how OpenGL performs from the libraries shipped with MinGW on CodeBlocks for windows:

http://megalomaniacbore.blogspot.co.uk/2014/05/setting-up-codeblocks-on-windows.html

From the project menu you can easily create a Test OpenGL project and build it... I assume its running in Mesa/Software... But it runs...

Aside from this, I have Wednesdays Post for the Virtual CPU project done, it was actually written last week, but I've had some problems uploading the two videos for it to YouTube.  I hope with the machine tuned up to upload them this evening.  Even if the videos are not present, the post is scheduled to go... And it covers Interrupts.

Setting up Code::Blocks & Boost on Windows

Updated for 2016: https://youtu.be/Mioo8Hnp6M8

Below is an older post, please see the new YouTube Video, like subscribe & if you benefited the tip jar is just there on the right!

Xel - 5th JUne 2016.

---

Building boost with Mingw32, installed via CodeBlocks....

First things first, download the installer for CodeBlocks for Windows, I selected the mingw32 compiler, at the time of writing this is:

codeblocks-13.12mingw-setup.exe

From the downloads page.

A quick example program can then be thrown together from the IDE, I'm interested in pure C++ using C++11, so I set the compiler to use -std=c++11 switches, as well as fix up the warning settings.

Once we're happy with the test project in the IDE we can go to the same file in a command prompt:

What we've just seen is, adding the compiler installed by codeblocks to the environment path:

PATH=%PATH%;C:\program files\CodeBlocks\MinGW\bin

We then edited the file with note pad:

#include <iostream>

using namespace std;

int main ()

{

cout << "Hello World" << endl;

}

Then from the command line we built the program:

mingw32-g++ -std=c++11 -Wall -o main.exe main.cpp

This gave us our application, and we could run "main.exe".

Now we've got all that working, my project uses the C++ boost libraries, so we need to build them with the mingw32 tools we've installed.

So, again we need a command prompt and the same PATH setting we have above:

PATH=%PATH%;C:\program files\CodeBlocks\MinGW\bin

Then from the boost folder we've extracted the boost source to, we need to build the boost build engine:

bootstrap.bat mingw

Once this is complete, we can build the libraries themselves:

b2 toolset=gcc

We now have the libs for linking in the boost sub folder /stage/lib

And we can find the headers in /boost...

We won't cover accessing them through the command line, instead BACK TO CODE BLOCKS!

So, we fire up code blocks, create a new project, its empty, we create our main.cpp and add "Hello World" in there.

We set the compiler to "-Wall" and "-Weff" and "=std=c++11", and check the compile & link worked.

Then we have to add the boost libraries, these are the system library, now we are in debug mode for this project, so we link against the libboost-system library with an added 'd' for debug.  If we switch to release with the drop down at the top, we need to add the link to the library which is not debug!

We also add the libboost-filesystem library, again in debug.

Finally, in the search directories we tell everything were to find boost itself, this allows our #includes to find boost headers.

I keep the paths relative, so I know whether I move my code and boost to "C:\Code" or "C:\Users\Jon\Desktop" the paths will be okay.

Then in the code, we'll include a check for a file on the file system, so include the boost filesystem header.  Then we add a path to "C:\hello.txt", and an exists check on that file...

CODE::BLOCK BUG/QUIRK!

And we build, now this is the first quirk you'll find, if you just build now the compiler will go off and start to rebuild boost... This is just stupid, so as the text is streaming past, ABORT the build, and then right click on the source file and build from there, you should see nothing needs doing.  Then rebuild again and the project is done almost instantly, this is a quirk of Code::Blocks, as it caches boost into the list of items built.... But we already built boost... 

Follow the video, it'll make sense.

#include <iostream>

#include <string>

#include <boost/filesystem.hpp>

using namespace std;

int main ()

{

    cout << "HEllo World" << endl;

    cout << "Testing if \"C:\\Hello.txt\" exists" << endl;

    boost::filesystem::path l_path("c:\\Hello.txt");

    if ( boost::filesystem::exists(l_path) )

    {

        cout << "File does exist!" << endl;

    }

    else

    {

        cout << "File missing" << endl;

    }

}

From the command line, we would have to add "-l libboost_system-mgw47-mt-d-1_55.a" and "-l libboost_filesystem-mgw47-mt-d-1-55.a", to link against boost.

The boost libraries we have are of course the dynamic libraries, if you wish to contain the libraries into the application you're distributing rather than having to hand out the libraries you've also built, you need to build the application static and rebuild boost with the static flags, which is a topic for another day.

Code::Blocks from Source on Linux (Debian) Mint

I've had a bit of a programming tools review, especially on my Linux boxes.  I've been using the stable release of Code::Blocks 12 for a long time, the reason being the lack of time and space to evaluate the newer v13.

Today however, the boss is out of the office, and with two projects under test I'm not going to do any more project progression for the next two days... This is therefore my window of opportunity... My chance to try v13!

And just to add to my thrill... God I'm sad... I built it from source...

For my own records then, my steps were...

1. Install the dependencies...

  sudo apt-get update

  sudo apt-get upgrade

  sudo apt-get install gtk+-2.0

  sudo apt-get install libwxgtk2.8-dev

  sudo apt-get install libwxbase2.8-dev

2. Download the source http://www.codeblocks.org/downloads

3. Extract to a folder and within...

  ./configure
  sudo make

  sudo make install

4. Edit the ld.so.conf

  sudo nano /etc/ld.so.conf

- Add -

include /usr/local/lib

- Save -

  sudo ldconfig

5. Run Code Blocks!

So far my tests have been fine, the project all load, and better than all this... My main project compile time has gotten a lot shorter, I'm talking we've gone from 1m8s on v12 to 48seconds... This may sound like nothing, but extend this out over 137 projects... That's just over 45 minutes on a full system rebuild for the main project.

Code::Blocks - A few Tips

I'm trying to set up a new Linux box to do some code (C++) in code blocks, now I do like how easy linking with multiple libraries is with code blocks - rather than fiddling with the command line or creating a make file which can obfuscate your build results...

But I'm not a huge fan of Code::Blocks, my biggest problems at the moment is I have a huge screen resolution, but no-matter how big it never feels like I've got enough workspace area available, it sort of feels hemmed in, this mainly comes from the poor way you can't layout editor windows side by side, or horizontally.  Forcing you to feel one file open at a time.

Then add to this that some of the editor settings pages - like "Settings->Environment" - full the whole height of the screen.  So you're there trying to edit the editor and you have this whole page filled with settings, and just as annoyingly you can't click off the editor settings back into the editor to look at something you've changed... You have to accept the settings, close the settings page and then you can see what you've done, this disjoints what you've changed from what you're viewing.

But I have a couple of tips to help you make things better.. First of all, pop into the View table and turn on the TODO list

Dock the panel for to-do items wherever you like...

And then you can add simple "// TODO MESSAGE" type items into your code to remind you what you're up to.

Another tip, if you want to maximise your coding area, you can close the messages windows - where the build output and messages go - but then getting them back open is a pain... To open them again, just press F2!

And finally, another one to maximise your working space, the editor tab showing the filename you're typing in.. Double click it... This will move into the maximised area version of the editor (by default) its a new theme called "Code::Blocks::Minimal".  If this is not setup then you can go into "Settings -> Environment" and then select the "View" (eyeball) on the right, and you're looking to make sure that this setting is selected: