Thursday, April 18, 2013

Nerd Food: Restoring a file from Git history

Nerd Food: Restoring a file from Git history

A common problem I've had with git in the past is how to restore a file from history. As it turns out, like with many things in git, it is quite easy once you know what you're looking for.

First we need to locate the file. For this we look at all paths affected by the commits we have done over time, so git log is a perfect suitor:

$ git log --all --name-only --pretty=format: | grep -i ecore
diagrams/other/Ecore.dia
diagrams/Ecore.dia
diagrams/other/Ecore.dia
diagrams/Ecore.dia
doc/diagrams/Ecore.dia
doc/diagrams/Ecore.dia

As I'm not really bothered as to which commit did what to this file, I just picked one of these paths. You may need to look into history and try to figure out which version is the one you're after. Now we need to figure out the SHA key:

$ git log -- diagrams/Ecore.dia | grep commit
commit f2d763df8b3775a9370ed43e00e3c28a07190932
commit a183879d848f32cd0f8b14c3b4b707f2b4946ca5

I'm sure you could do both of these steps in one go, but I'm too lazy to find out how. Finally, just checkout the blob from the object database:

$ git checkout a183879d848f32cd0f8b14c3b4b707f2b4946ca5 -- diagrams/Ecore.dia
$ head diagrams/Ecore.dia
<?xml version="1.0" encoding="UTF-8"?>
<dia:diagram xmlns:dia="http://www.lysator.liu.se/~alla/dia/">
  <dia:diagramdata>
    <dia:attribute name="background">
      <dia:color val="#ffffff"/>
    </dia:attribute>
    <dia:attribute name="pagebreak">
      <dia:color val="#000099"/>
    </dia:attribute>
    <dia:attribute name="paper">

It's that easy!

Date: 2013-04-18 23:51:11 BST

Org version 7.8.02 with Emacs version 23

Validate XHTML 1.0

Friday, March 22, 2013

Nerd Food: Interesting

Nerd Food: Interesting…

Some interesting stuff I bumped into these last couple of weeks.

C++

Other Programming Topics

Other

  • Charles Bradley: Soul of America: Here's a guy that just didn't know when to call it quits! Fame at the late age for Charles Bradley. Great voice.
  • UN The Movie: From the trailer, seems like a must watch - if a bit cringe-worthy. Documentary (or mockumentary…) in the vein of Michael Moore.
  • Brazil make it funky vol.2: Some cool tunes from our Brazilian brothers to keep us warm in this cold, cold spring.

Portugues

  • Depois do Adeus: Serie sobre os retornados das ex-colonias Lusofonas. Muito bem feita.

Date: 2013-03-22 20:29:56 GMT

Org version 7.8.02 with Emacs version 23

Validate XHTML 1.0

Thursday, March 21, 2013

Nerd Food: Installing Wt from Git

Nerd Food: Installing Wt from Git

On my copious free time I've been playing around with wt. I was always curious about a C++ based web framework, but with the recently added bootstrap support I just couldn't resist! Here are the steps to build it from source, into our PFH chroot.

First clone their mirror git repo:

mkdir wt
cd wt
git clone git://github.com/kdeforche/wt.git git

Then build it with a few additional parameters:

mkdir build
cd build
cmake -DRUNDIR=/usr/local/pfh/var/run/wt -DCONFIGDIR=/usr/local/pfh/etc/wt -DCMAKE_INSTALL_PREFIX=/usr/local/pfh -DBoost_NO_SYSTEM_PATHS=true -DBOOST_ROOT=/usr/local/pfh ../git
make -j4

Then install it:

make install

That's it! Now to configure apache to run the examples…

Date: 2013-03-21 07:21:50 GMT

Org version 7.8.02 with Emacs version 23

Validate XHTML 1.0

Tuesday, March 19, 2013

Nerd Food: Installing Latest Stable ODB

Nerd Food: Installing Latest Stable ODB

We recently started to add ODB support to Dogen in anger, so time came to update our build farm with the latest ODB. Previously we had hit a minor snag with C++ 11 but its all good with latest stable so that's what we're going with. In Debian, since we already had GCC 4.7, all we had to do was to su to root and install the plugin support:

apt-get install gcc-4.7-plugin-dev

Then it was as easy as the three magic steps (PFH is our local chroot):

mkdir build
cd build

wget http://www.codesynthesis.com/download/libcutl/1.7/libcutl-1.7.0.tar.gz
tar xaf libcutl-1.7.0.tar.gz
cd libcutl-1.7.0
./configure --prefix=/usr/local/pfh
make -j4
make install
cd ..

wget http://www.codesynthesis.com/download/odb/2.2/odb-2.2.1.tar.gz
tar xaf odb-2.2.1.tar.gz
cd odb-2.2.1
./configure --prefix=/usr/local/pfh
make -j4
make install
cd ..

Wit this you now have the ODB compiler ready to rock and roll. However, in order to be able to use it you need the supporting libraries. We only care about postgres and boost, so that's all we installed:

wget http://www.codesynthesis.com/download/odb/2.2/libodb-2.2.2.tar.gz
tar xaf libodb-2.2.2.tar.gz
cd libodb-2.2.2
./configure --prefix=/usr/local/pfh
make -j4
make install
cd ..

wget http://www.codesynthesis.com/download/odb/2.2/libodb-pgsql-2.2.0.tar.gz
tar xaf libodb-pgsql-2.2.0.tar.gz
cd libodb-pgsql-2.2.0
./configure --prefix=/usr/local/pfh
make -j4
make install
cd ..

wget http://www.codesynthesis.com/download/odb/2.2/libodb-boost-2.2.0.tar.gz
tar xaf libodb-boost-2.2.0.tar.gz
cd libodb-boost-2.2.0
./configure --prefix=/usr/local/pfh
make -j4
make install
cd ..

Things were not so easy for platforms other than Linux - as it always tends to be the case! This is because we built GCC previously without --enable-plugin so to be able to use the ODB compiler one would have to rebuild GCC. Luckily we don't really need to use the ODB compiler on all platforms - we just need to be able to build the code on all platforms - so we coped out and build only the supporting libraries on both OSX and Windows.

The tests pass just fine across the board, so basic ODB support is now in Dogen. This is of course the initial implementation so its still rather hacky, but at least it proves the concept. Next to clean up the tests and to generate the makefiles directly from Dogen.

Date: 2013-03-19 22:23:59 GMT

Org version 7.8.02 with Emacs version 23

Validate XHTML 1.0

Nerd Food: Installing Clang Unstable on Debian Testing

Nerd Food: Installing Clang Unstable on Debian Testing

We find clang an extremely useful development compiler. Not only does it pick up errors that GCC tends to ignore, but it also provides us with a completion mode in emacs that works surprisingly well.

So it was with great sadness that, for some inexplicable reason, our clang 3.1 build started failing after a dist-upgrade. After trying some obvious fixes such as doing a clean build and so on - to no avail - I decided to investigate clang 3.2, which has already hit experimental. Hey, worth a go right?! I've never been brave enough to start pinning packages from experimental into testing - always afraid to upgrade something by mistake. Clang tends to be really easy to install by hand so its not a problem to handle dependencies manually. This was almost the case with 3.2.

First start by removing all the old LLVM and clang packages you got lying around. They are actually side-by-side installable for the most part, but I strongly believe its a bad idea to have these versions lying around unless you have very good reason to do so. Last thing you need is to use the incorrect version of the compiler and start getting some weird errors.

Downloading the required packages is pretty straightforward:

mkdir clang-3.2
cd clang-3.2
wget http://ftp.us.debian.org/debian/pool/main/c/clang/libclang-dev_3.2-1~exp8_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/c/clang/libclang1_3.2-1~exp8_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/l/llvm-3.2/llvm-3.2-runtime_3.2-3_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/l/llvm-3.2/llvm-3.2_3.2-3_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/l/llvm-3.2/llvm-3.2-dev_3.2-3_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/l/llvm-3.2/libllvm3.2_3.2-3_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/c/clang/libclang-common-dev_3.2-1~exp8_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/c/clang/compiler-rt_3.2-1~exp8_amd64.deb
wget http://ftp.us.debian.org/debian/pool/main/c/clang/clang-3.2_3.2-1~exp8_amd64.deb

To install them su to root and dpkg them in the correct order:

dpkg -i libllvm3.2_3.2-3_amd64.deb
dpkg -i llvm-3.2-runtime_3.2-3_amd64.deb
dpkg -i llvm-3.2_3.2-3_amd64.deb
dpkg -i llvm-3.2-dev_3.2-3_amd64.deb
dpkg -i libclang1_3.2-1~exp8_amd64.deb
dpkg -i libclang-common-dev_3.2-1~exp8_amd64.deb
dpkg -i libclang-dev_3.2-1~exp8_amd64.deb
dpkg -i compiler-rt_3.2-1~exp8_amd64.deb
dpkg --force-depends -i clang-3.2_3.2-1~exp8_amd64.deb

You won't fail to notice the extremely worrying --force-depends at the very end. This is because to reasons unknown to me, clang now depends on libgcc-4.7-dev and libobjc-4.7-dev. These packages are not yet available in testing and last thing you need is to pull GCC straight of unstable. Assuming that any dependency between clang and GCC is probably either a mistake or something optional, I decided to force an install anyway and see how the compiler behaved. As it turns out the compiler worked just fine so I'm not loosing any sleep over the missing dependency just yet.

Unfortunately the hacks don't end there. We also found that libprofile_rt never quite gets found, so an additional hack is required (as root):

cd /usr/lib
rm libprofile_rt.a libprofile_rt.so
ln -s /usr/lib/llvm-3.2/lib/libprofile_rt.a
ln -s /usr/lib/llvm-3.2/lib/libprofile_rt.so

Interestingly, the warnings on clang 3.2 are even better than on 3.1 and so it picked up a number of unused member variables in your code, which we duly fixed. Hopefully it will all go green on tomorrow's clean builds.

Date: 2013-03-19 21:59:47 GMT

Org version 7.8.02 with Emacs version 23

Validate XHTML 1.0

Friday, June 08, 2012

Nerd Food: Installing Wine Unstable on Debian Testing

Nerd Food: Installing Wine Unstable on Debian Testing

So it seems we're still on Wine 1.2 on Debian Testing. In Wine terms that's like really old. WineHQ does point to a site which has recent builds of Wine unstable for sid, so I thought I'd install them. Unfortunately, the chap doesn't provide an apt-gettable repository - by design, it seems - so we need to do it the hard way.

Before you start, make sure you have no remnants of a wine install. I found that these debs are not side-by-side installable with the previous version, so I removed all of wine from synaptic. If, on the steps below you see errors like this, then you still have an old installation of wine:

conflicting packages - not installing libwine-alsa-unstable

You have been warned. The first step is to get all the debs. I'm on Intel 64-bit so I grabbed the AMD-64 build. If you're on Intel 32-bit, be sure to download the correct i386 packages. For 64-bit just do:

mkdir wine_1.5.5
cd wine_1.5.5
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-alsa-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-bin-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-capi-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-cms-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-dbg-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-dev-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-gl-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-gphoto2-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-ldap-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-openal-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-oss-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-print-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-sane-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/libwine-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/wine-bin-unstable_1.5.5-0.1_amd64.deb
wget http://dev.carbon-project.org/debian/wine-unstable/wine-unstable_1.5.5-0.1_amd64.deb

To install them su to root and dpkg them in the correct order (well, a correct order I guess):

dpkg -i libwine-unstable_1.5.5-0.1_amd64.deb
dpkg -i libwine-alsa-unstable_1.5.5-0.1_amd64.deb
dpkg -i libwine-bin-unstable_1.5.5-0.1_amd64.deb
dpkg -i libwine-capi-unstable_1.5.5-0.1_amd64.deb
dpkg -i libwine-cms-unstable_1.5.5-0.1_amd64.deb
dpkg -i libwine-gl-unstable_1.5.5-0.1_amd64.deb
dpkg -i libwine-gphoto2-unstable_1.5.5-0.1_amd64.deb
dpkg -i libwine-ldap-unstable_1.5.5-0.1_amd64.deb
dpkg -i libwine-openal-unstable_1.5.5-0.1_amd64.deb
dpkg -i libwine-oss-unstable_1.5.5-0.1_amd64.deb
dpkg -i libwine-sane-unstable_1.5.5-0.1_amd64.deb
dpkg -i wine-bin-unstable_1.5.5-0.1_amd64.deb
dpkg -i libwine-print-unstable_1.5.5-0.1_amd64.deb
dpkg -i wine-unstable_1.5.5-0.1_amd64.deb

That's it! We can now run wine:

$ wine --version
wine-1.5.5

Interestingly, whilst apps ran just fine and sound worked out of the box, I found myself unable to use the video camera. Apparently this is due to some issue with v4l:

The v4l headers were not available at compile time,
so video capture support is not available.

This requires some investigation.

Date: 2012-06-08 12:12:27 BST

Org version 7.8.02 with Emacs version 23

Validate XHTML 1.0

Thursday, June 07, 2012

Nerd Food: C++-11 with GCC

Nerd Food: C++-11 with GCC

Standard Disclaimer: as with all posts in Nerd Food, this is a summary of my notes and experience on the subject. Its likely there will be incorrect bits of information so don't start building your personal nuclear power station using this article. Or if you do, don't blame me.

Compiling a compiler has become a necessity for all of us living in the bleeding edge of C++-11. After all, who wants to wait for the next stable release of INSERT_FAVOURITE_COMPILER and then for INSERT_FAVOURITE_DISTRIBUTOR to start packaging them! We've already covered how to build and install Clang from source and use it to compile and run a trivial hello world; it seems only fitting to do the same thing for GCC.

A couple of notes on the content that follows:

  • the post focuses more on Linux but we also try to give some pointers for Windows (MinGW) and MacOSX. Testing was done on Windows XP and OSX Lion respectively.
  • we're targeting version 4.7 but you should be able to apply these instructions to svn trunk builds too - assuming you have the correct versions of the dependencies. We may cover that specific scenario on a later post.
  • we are - of course - assuming that you are using an older version of GCC to build GCC. You could try to use Clang or another compiler, but we didn't.

Prerequisites

Rather unfortunately, one of the requirements for building a compiler is a working compiler. In addition, there is always a bit of fiddling required. Lets go through each platform in turn.

Debian Testing

Debian is going through the multi-arch transition at the moment, which complicates things. For instance, for reasons unknown we need to install 32-bit glibc development headers - even when building on 64-bit. The easiest way to do so is to install multi-platform support for the system GCC:

sudo apt-get install g++-multilib

In addition, its probably best to set the LIBRARY_PATH so we can tell the linker about it:

export LIBRARY_PATH=/usr/lib/x86_64-linux-gnu

If you don't, you'll probably experience weird C runt-time errors:

/usr/bin/ld: cannot find crt1.o: No such file or directory
/usr/bin/ld: cannot find crti.o: No such file or directory
collect2: ld returned 1 exit status

MacOSX

Grab XCode - or even better, just the Command Line Tools bundle - and make sure its installed and working. If all has gone well, the following should work when you open up a terminal:

gcc --version

MinGW

We need to get a compiler on Windows before we can compile. We'll only cover the MinGW scenario. First get the main installer from MinGW and run it. During the setup choose the following options:

  • Repository catalogues: download latest repository catalogues.
  • Set destination location: Choose something like C:\MinGWRoot. The post-fix root is actually important because we will use c:\mingw later. Basically, choose any name other than \mingw on the chosen given drive.
  • Select Components: make sure "C Compiler", "C++ Compiler", "MSYS Basic System" and "MinGW Developer Toolkit" are ticked.

Click install and wait - it will take a while as it downloads all the packages. When finished, start the MinGW shell from the Start Menu and make sure the following works:

gcc --version

The next thing to do - a bit of a hack really - is to create an "identity" "mount". This is another way of saying that the MSYS1 root is actually the same as the windows root. The "cleanest" way to do this is to use junction which you can easily grab from SysInternals:

mingw-get install msys-wget
wget http://live.sysinternals.com/junction.exe
junction c:\\mingw C://MinGWRoot/msys/1.0

Now set the linker path pointing it to the identity mount:

export LIBRARY_PATH="/mingw/lib"

If you don't, you may experience the following error:

C:\MinGWRoot\mingw32\bin\ld.exe: cannot find dllcrt2.o: No such file or directory
collect2.exe: error: ld returned 1 exit status
make[3]: *** [libgcc_s.dll] Error 1
make[3]: Leaving directory `/home/marco/gcc-4.7.0_obj/i686-pc-mingw32/libgcc'

Building and Installing

Let's get started with the actual compilation. First we need to install the dependencies; you can peruse the prerequisites page for more details. I'm normally lazy and go with GMP, MPFR and MPC. This means we're not getting all the Graphite goodies which require PPL2.

The correct order of dependencies is as follows: GCC depends on MPC, which depends on MPFR, which depends on GMP; so the order of installation is:

  • GMP
  • MPFR
  • MPC
  • GCC

So we start by installing GMP (replace the --jobs 2 flag with the number of cores available on your machine):

wget ftp://ftp.gmplib.org/pub/gmp-5.0.4/gmp-5.0.4.tar.bz2
tar xjf gmp-5.0.4.tar.bz2
cd gmp-5.0.4
./configure --prefix=${HOME}/local
make --jobs 2
make install
cd ..

If you are on a recent version of Linux you can use the brand-spanking xaf incantation of tar, which unpacks any archive type; in the interest of backwards compatibility we're sticking with the old invocations here.

Now we can install MPFR:

wget http://www.mpfr.org/mpfr-current/mpfr-3.1.0.tar.bz2
tar xjf mpfr-3.1.0.tar.bz2
cd mpfr-3.1.0
./configure --prefix=${HOME}/local --with-gmp=${HOME}/local
make --jobs 2
make install
cd ..

Note that we are using --with-gmp instead of using the traditional CFLAGS and LDFLAGS. This is a pattern followed through on GCC configuration; I highly recommend you follow it as I'm sure a lot of other things are happening on the background other than setting those environment variables. In fact you may want to even make sure these variables are not set to avoid any weird compilation problems.

MPC is installed next:

wget http://www.multiprecision.org/mpc/download/mpc-0.9.tar.gz
tar xf mpc-0.9.tar.gz
cd mpc-0.9
./configure --prefix=${HOME}/local --with-gmp=${HOME}/local \
--with-mpfr=${HOME}/local
make --jobs 2
make install
cd ..

Finally, we can now install GCC. Up til now we've been lazy and done in-source builds. This is normally frowned upon, but doesn't have any major consequences - that is, with the exception of GCC. The documentation states explicitly that this is not a good idea:

First, we highly recommend that GCC be built into a separate directory from the sources which does not reside within the source tree. This is how we generally build GCC; building where srcdir == objdir should still work, but doesn't get extensive testing; building where objdir is a subdirectory of srcdir is unsupported.

We're not that brave so we'll follow the recommendation. We compile GCC as follows:

wget http://ftp.gnu.org/gnu/gcc/gcc-4.7.0/gcc-4.7.0.tar.bz2
tar xjf gcc-4.7.0.tar.bz2
mkdir gcc-4.7.0_obj
cd gcc-4.7.0_obj
../gcc-4.7.0/configure --prefix=${HOME}/local \
--enable-ld=yes --disable-nls --with-gmp=${HOME}/local \
--with-mpfr=${HOME}/local --with-mpc=${HOME}/local \
--program-suffix=-4.7 --enable-checking=release --enable-languages=c,c++
make --jobs 2
make install

Lets see in detail the more important GCC configuration options:

  • disable-nls: unless you are into internationalisation, you don't really need NLS. This shaves off a bit of build time.
  • enable-checking: lets make a few checks - no one wants a compiler that generates broken code.
  • enable-languages: we are only interested in C/C++, so no point in building ADA, Java, etc.
  • enable-ld: we're being old-school here and using traditional ld instead of gold, the new linker written in C++.

On the whole, these basic instructions are sufficient to build GCC on Linux, MacOSX and Windows (MinGW). However, when you leave Linux there is always a bit of platform-specific fiddling required. And to be fair, Debian testing also had a couple of wrinkles.

Compiling Hello World

In order to prove that we have a valid setup, lets create a trivial hello world, with a hint of C++-11:

#include <iostream>

int main(void) {
    auto hello = std::string("hello world");
    std::cout << hello << std::endl;
}

First lets make sure we have our prefix directory on the path:

export PATH=$PATH:${HOME}/local

Now we can then compile with our shinny new GCC:

g++-4.7 -c hello.cpp -std=c++11
g++-4.7 -o hello hello.o -std=c++11

Running Hello World

Running hello world is a bit trickier. We now need to tell the program loader about it and this varies from operative system to operative system.

Debian

Due to the multi-arch changes, we need to point the program loader directly to the arch specific directory:

export LD_LIBRARY_PATH=${HOME}/local/lib64

To verify that your binaries are setup correctly, use ldd:

$ ldd hello
    linux-vdso.so.1 =>  (0x00007fffda7ff000)
    libstdc++.so.6 => /home/marco/local/lib64/libstdc++.so.6 (0x00007f6931fa2000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6931cf8000)
    libgcc_s.so.1 => /home/marco/local/lib64/libgcc_s.so.1 (0x00007f6931ae2000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f693175b000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f69322d1000)

Note that both the C++ run-time and the GCC's shared object were picked up from the correct location.

MacOSX

Apple - thinking differently as usual - doesn't use binutils. This means ld, gold, as etc are all a bit different. Darwin doesn't use ELF like every other sensible UNIX but it uses MACH-O instead - a bad nerd pun, if I ever seen one. In general this shouldn't really affect you - except you can't use familiar tools such as ldd etc.

Lets start by getting the program loader to point to our lib directory:

export DYLD_LIBRARY_PATH=${HOME}/local/lib

To verify that your binaries are setup correctly, use otool:

otool -L hello
hello:
    /Users/marco/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.17.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
    /Users/marco/local/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

Here you can see that the C++ run-time and the GCC dynamic library where picked up from the correct location.

MinGW

On Windows the program loader path is not important, it's the main PATH variable you have to worry about3. Thus the DLLs must be on the PATH rather than on the usual variables for the program loader path. To do so:

$ export PATH=${HOME}/local/bin:${PATH}

Notice we placed our directory first in the path - this is to avoid picking up the wrong DLLs from the stock compiler. Running produces the desired output:

$ ./hello.exe
hello world

To double-check we are indeed using the correct DLLs we need to install Dependency Walker. I installed mine to C:\packages - hey, why not. You can then run:

$ c:/packages/depends.exe

And you should see something akin to this:

Dependency Walker

Dependency walker with hello world

Uninstalling

Word of caution: notably, GCC isn't built with uninstall in mind. It doesn't support the unistall target some tarballs provide and many dicussions strongly advise against its complete manual uninstall. This is why we chose a careful location to install it, so we can simple do:

rm -rf ${HOME}/local

Conclusions

As you can see its really easy to build GCC from source, install it and start using it to compile C++-11 programs. In future we will cover how to compile auxiliary libraries such as boost with C++-11 support so you can use the full power of the language.

Footnotes:

1 : I won't go in to too much detail on the finer points between MinGW and MSYS and so on; if you are interested, check the post MinGW, Cygwin and Wine.

2 I had one or two problems when compiling PPL in the past so I gave up on it, and haven't noticed significant optimisation problems yet. Of course, if this was a production compiler I certainly would compile it with PPL.

3 Or better yet, the windows loader uses only one path variable for both the executables and the shared libraries.

Date: 2012-06-08 08:43:47 BST

Org version 7.8.02 with Emacs version 23

Validate XHTML 1.0