Sunday, March 04, 2012

Nerd Food: Going Native

If, like me, you are into C++ and particularly C++11 you will want to watch Going Native 2012. I must say I had problems playing both the original live stream (in Silverlight) and the downloadable WMVs. The MP4s however work just fine. For convenience I created a list of wgettable URLs. You can replace the "low" bit of the URL with "med" or "high" depending on the desired resolution; I found the low perfectly watchable, but then again it seems I have pretty low sensitivity to video quality.

#!/bin/sh

wget http://video.ch9.ms/ch9/252f/ed5c3dc3-3335-493b-9e2c-9fd00012252f/GoingNative2012KeynoteStroustrup_low_ch9.mp4
wget http://video.ch9.ms/ch9/b54e/8ceeaa3d-551e-4184-a964-9fd4012cb54e/GoingNative2012ThreadsSharedVar_low_ch9.mp4
wget http://video.ch9.ms/ch9/a855/e5f3aeb9-5917-42ee-85d9-9fd4012da855/GoingNative2012STL11_low_ch9.mp4
wget http://video.ch9.ms/ch9/5174/7feb4b38-591d-478f-8341-9fd4012d5174/GN12AndreiAlexandrescuVariadicTemplates_low_ch9.mp4
wget http://video.ch9.ms/ch9/aeff/4c406d50-69f7-4400-9d40-9fd50010aeff/GN12PanelImportanceOfBeingNative_low_ch9.mp4
wget http://video.ch9.ms/ch9/6206/8d17c664-55c8-4d6c-8fbc-9fd000166206/Day2KeynoteHerbSutter_low_ch9.mp4
wget http://video.ch9.ms/ch9/8457/11183d54-55a6-43e6-9a0e-9fd7015b8457/GN12ChandlerCarruthClang_low_ch9.mp4
wget http://video.ch9.ms/ch9/f5e4/046c6a82-3d47-416b-a22e-9fd4012bf5e4/AndreiDay2_low_ch9.mp4
wget http://video.ch9.ms/ch9/71d4/a4e5fc51-29d9-4b15-9eb0-9fd7015871d4/GN12StroustrupSuttonConceptDesign_low_ch9.mp4
wget http://video.ch9.ms/ch9/355a/08a0858f-93d5-4148-ae86-9fd7015a355a/GN12PanelAskUsAnything_low_ch9.mp4


Saturday, February 04, 2012

Nerd Food: Adventures in F# Land - Part 3

So the hackery continues. Before I go any further I'd like to say that none of the solutions on this series of blog posts are "real" solutions; you shouldn't really be hacking debs and installing them as root - at least not on your main box, at any rate. If you want to do any of this you should really fire off a VM - its really trivial these days what with Qemu and that. Hopefully when we get to the end of this we can submit some real patches to those in charge.

Warnings out of the way, we can now focus on fixing the problems we bumped into last time. Turns out the first one was actually quite straight forward. The error we were getting was:
Missing method .ctor in assembly /usr/lib/fsharp/FSharp.Core.dll, type System.Security.SecurityRulesAttribute
A quick google revealed that this is a symptom suffered by all of those who are silly enough to use a non 4.0 runtime with an application/assembly that requires it. As it happens, the mono guys renamed their compiler with the 4.0 upgrade; gmcs is no longer, long live dmcs. Hey, its a solution as good as any and it avoids confusion I guess. In fact, it appears this compiler-name-changing thing is rather common in mono-land because the F# AddIn guys even put in a configure option to pass in the compiler:
-c Path/name of the C# compiler executable or script
('mono' is NOT automatically added to the front)
Default value: gmcs
So all that was required to fix this problem is to pass in the correct compiler:
$ ./configure.sh -c dmcs
This took as to the next error, the infamous --resident:
error FS0243: Unrecognized option: '--resident'
Googling didn't help with this one, and if you recall, my grepping didn't either. It turns out the problem was with the wrapper scripts the deb offers us:

$ cat /usr/bin/fsharpc
#!/bin/sh
exec mono /usr/lib/fsharp/fsc.exe --resident "$@"

Since we're on a hacking mood, I just su'd to root and updated the contents of this file as follows (notice the runtime parameter being passed in to mono):
$ cat /usr/bin/fsharpc
#!/bin/sh
exec mono --runtime=v4.0 /usr/lib/fsharp/fsc.exe "$@"
With this, we got the F# compiler to actually do some compilation for us. It then moaned about a missing reference to Cairo, which we can easily fix:
diff --git a/Makefile.orig b/Makefile.orig
index a88a8a8..52caf12 100644
--- a/Makefile.orig
+++ b/Makefile.orig
@@ -57,6 +57,8 @@ FILES = \
src/FSharpResolverProvider.fs
REFERENCES = \
+ -r:$(MONOBIN)/Mono.Cairo.dll \
And now we get to the real error: unfortunately the MonoDevelop code has moved on - hey, we've upgraded from 2.4 to 2.10, _something_ had to change, right!

Microsoft (R) F# 2.0 Compiler build 4.0.30319.1
Copyright (c) Microsoft Corporation. All Rights Reserved.

\home\marco\Development\fsharpbinding\src\PowerPack\CodeDomGenerator.fs(248,44): warning FS0044: This construct is deprecated

\home\marco\Development\fsharpbinding\src\Services\Common.fs(11,11): error FS0039: The namespace 'Addins' is not defined

\home\marco\Development\fsharpbinding\src\Services\Common.fs(381,39): error FS0039: The namespace or module 'AddinManager' is not defined

\home\marco\Development\fsharpbinding\src\Services\Common.fs(383,9): error FS0039: The namespace or module 'AddinManager' is not defined

\home\marco\Development\fsharpbinding\src\Services\Common.fs(397,39): error FS0039: The namespace or module 'AddinManager' is not defined

\home\marco\Development\fsharpbinding\src\Services\Common.fs(399,9): error FS0039: The namespace or module 'AddinManager' is not defined
make: *** [all] Error 1
So now we need to get our hands dirty and learn a bit about MonoDevelop's internals. But that's a matter for the next episode.

Update: It seems we're not the first trying to go down this route! Github has a really nice ticket detailing other interpid explorers going down this exact same route!


I'll parse the ticket and see where it will take us!

Nerd Food: Adventures in F# Land - Part 2

And so the adventures in F# continue. After some digging, I found out that the "sources" for F# are actually available on mercurial in CodePlex, as part of fsxplat. To obtain them, just clone as one would with git:
$ hg clone https://hg01.codeplex.com/fsxplat fsxplat
I say "sources" because there wasn't a lot of source code; its mainly the skeleton of a debian package, that uses a shell script to go away and download the F# binaries. The work is all done inside of make_package.sh and the binaries are available from Microsoft's download website; I even found an updated version here but decided against using it, in case the changes caused further problems.

To my great joy, perusing the zip file revealed a 4.0 build of the F# compiler. I made some surgical modifications to make package, as follows:
$ hg diff
diff -r 4d371abd932f make_package.sh
--- a/make_package.sh Sun Jan 01 22:39:08 2012 +0100
+++ b/make_package.sh Sat Feb 04 17:30:29 2012 +0000
@@ -7,13 +7,20 @@
mv FSharp-2.0.0.0/* fsharp
rmdir FSharp-2.0.0.0
rm fsharp.zip
+rm -rf fsharp/bin
+mv fsharp/v4.0/bin fsharp/bin
+mv fsharp/bin/Fsc.exe fsharp/bin/fsc.exe
+mv fsharp/bin/Fsi.exe fsharp/bin/fsi.exe
cd fsharp
# get Mono key and re-sign the F# dll
# this trick will be removed once the following bug is closed:
# https://bugzilla.novell.com/show_bug.cgi?id=615445
-wget http://anonsvn.mono-project.com/source/trunk/mcs/class/mono.snk
+wget https://github.com/mono/mono/blob/master/mcs/class/mono.snk?raw=true -O mono.snk
sn -q -R bin/FSharp.Core.dll mono.snk
+sn -q -R bin/FSharp.Compiler.Interactive.Settings.dll mono.snk
+sn -q -R bin/FSharp.Compiler.Server.Shared.dll mono.snk
+sn -q -R bin/FSharp.Compiler.dll mono.snk
rm mono.snk
# make the package
Nothing particularly exciting: we delete the existing bin directory and replace it with the one provided in 4.0; we also update the path to mono's SNK file, as the svn server appears to be down; finally, we sign a few more DLLs while we're at it. With these changes one can create a new debian package:
$ ./make_package.sh
We leave the script to perform its magic and eventually one ends up with a lovely deb: fsharp_2.0-1_all.deb. If, like me, you're more comfortable with the command line, you can easily install the package from there:
$ su
# gdebi fsharp_2.0-1_all.deb
Amazingly, it all installs without any problems! So now that we have a 4.0 build of F# we can return to the F# bindings. Unfortunately, we're not quite there yet:
$ make
mkdir -p bin
gmcs -debug+ -out:bin/FSharpBinding.Gui.dll -target:library -r:/usr/lib/mono/4.0/Mono.Posix.dll -r:/usr/lib/mono/4.0/mscorlib.dll -r:System.dll -r:System.Xml.dll -r:/usr/lib/monodevelop/bin/MonoDevelop.Core.dll -r:/usr/lib/monodevelop/bin/MonoDevelop.Ide.dll -r:/usr/lib/monodevelop/bin/Mono.TextEditor.dll -r:/usr/lib/fsharp/FSharp.Core.dll -r:/usr/lib/fsharp/FSharp.Compiler.dll -r:/usr/lib/fsharp/FSharp.Compiler.Interactive.Settings.dll -r:/usr/lib/fsharp/FSharp.Compiler.Server.Shared.dll -r:/usr/lib/cli/atk-sharp-2.0/atk-sharp.dll -r:/usr/lib/cli/pango-sharp-2.0/pango-sharp.dll -r:/usr/lib/cli/gtk-sharp-2.0/gtk-sharp.dll -r:/usr/lib/cli/gdk-sharp-2.0/gdk-sharp.dll -r:/usr/lib/cli/glib-sharp-2.0/glib-sharp.dll src/Gui/FSharpBuildOrderWidget.cs src/Gui/FSharpSettingsWidget.cs src/Gui/FSharpCompilerOptionsWidget.cs src/Gui/gtk-gui/FSharp.MonoDevelop.Gui.FSharpBuildOrderWidget.cs src/Gui/gtk-gui/FSharp.MonoDevelop.Gui.FSharpSettingsWidget.cs src/Gui/gtk-gui/FSharp.MonoDevelop.Gui.FSharpCompilerOptionsWidget.cs src/Gui/gtk-gui/generated.cs
Missing method .ctor in assembly /usr/lib/fsharp/FSharp.Core.dll, type System.Security.SecurityRulesAttribute
Can't find custom attr constructor image: /usr/lib/fsharp/FSharp.Core.dll mtoken: 0x0a000006
fsharpc --noframework --debug --optimize- --target:library -r:bin/FSharpBinding.Gui.dll --out:bin/FSharpBinding.dll -r:/usr/lib/mono/4.0/Mono.Posix.dll -r:/usr/lib/mono/4.0/mscorlib.dll -r:System.dll -r:System.Xml.dll -r:/usr/lib/monodevelop/bin/MonoDevelop.Core.dll -r:/usr/lib/monodevelop/bin/MonoDevelop.Ide.dll -r:/usr/lib/monodevelop/bin/Mono.TextEditor.dll -r:/usr/lib/fsharp/FSharp.Core.dll -r:/usr/lib/fsharp/FSharp.Compiler.dll -r:/usr/lib/fsharp/FSharp.Compiler.Interactive.Settings.dll -r:/usr/lib/fsharp/FSharp.Compiler.Server.Shared.dll -r:/usr/lib/cli/atk-sharp-2.0/atk-sharp.dll -r:/usr/lib/cli/pango-sharp-2.0/pango-sharp.dll -r:/usr/lib/cli/gtk-sharp-2.0/gtk-sharp.dll -r:/usr/lib/cli/gdk-sharp-2.0/gdk-sharp.dll -r:/usr/lib/cli/glib-sharp-2.0/glib-sharp.dll --resource:src/Resources/FSharpBinding.addin.xml --resource:src/Resources/EmptyFSharpSource.xft.xml --resource:src/Resources/EmptyFSharpScript.xft.xml --resource:src/Resources/FSharpConsoleProject.xpt.xml --resource:src/Resources/fsharp-icon-32.png --resource:src/Resources/fsharp-script-32.png --resource:src/Resources/fsharp-file-icon.png --resource:src/Resources/fsharp-project-icon.png --resource:src/Resources/fsharp-script-icon.png --resource:src/Resources/FSharpSyntaxMode.xml src/PowerPack/CodeDomVisitor.fs src/PowerPack/CodeDomGenerator.fs src/PowerPack/CodeProvider.fs src/PowerPack/LazyList.fsi src/PowerPack/LazyList.fs src/Services/Mailbox.fs src/Services/Parameters.fs src/Services/FSharpCompiler.fs src/Services/CompilerLocationUtils.fs src/Services/Common.fs src/Services/Parser.fs src/Services/LanguageService.fs src/Services/CompilerService.fs src/Services/InteractiveSession.fs src/FSharpInteractivePad.fs src/FSharpOptionsPanels.fs src/FSharpSyntaxMode.fs src/FSharpResourceIdBuilder.fs src/FSharpLanguageBinding.fs src/FSharpParser.fs src/FSharpTextEditorCompletion.fs src/FSharpResolverProvider.fs
Microsoft (R) F# 2.0 Compiler build 4.0.30319.1
Copyright (c) Microsoft Corporation. All Rights Reserved.

error FS0243: Unrecognized option: '--resident'
make: *** [all] Error 1
So now we got two problems. The first one seems to be a dependency issue with F#'s core. The second one is even more worrying as it appears we are trying to use an invalid compiler option. Greping for resident on the AddIn sources didn't reveal who's attempting to use --resident, however.

Stay tuned for the next episode...



Nerd Food: Adventures in F# Land - Part 1

So me and the lads went to yet another event organised by SkillsMatters on F#. As usual the gurus were there, including Phil Trelford and Tomas Petricek, two very nice guys and fairly easy to approach. This time round they organised a kata around the pacman game, all in F#. Unfortunately, none of us was overly prepared and whilst I had my netbook on me, I didn't set it up with F# and associated tools. This was obviously a mistake as the kata was all about coding (duh!). So we spent a large amount of it trying to get F# going on Linux under pressure - not an experience that I'd recommend.

Now that the dust has settled, I thought I'd have a proper go. The key thing that triggered my attention was a massive update to my debian testing box this morning: nice and shiny mono 2.12 and MonoDevelop 2.10! These little babies target the 4.0 profile - none of that old stuff any more. Excellent news. So I got the dist-upgrade out of the way - fairly painlessly I might add, it just went straight through - fired off MonoDevelop and got myself to work (actually, in truth, the first thing I did was to setup F# mode in emacs, but I digress).

I started off by following Tomas instructions but noticed that things had moved on a bit since his video. For one, there are debs of F# in CodePlex these days: http://fsxplat.codeplex.com/releases/view/55463. I grabbed myself the deb - thinking it wouldn't really work on my 64-bit build, really - but it installed without any problems and even registered all the assemblies in the Gac. Nice one. Second step was to get the MonoDevelop AddIn working. Now this is were things didn't go so well. I dutifully went to Tools | AddIn Manager, Gallery, Clicked on the combo and selected Manage Repositories; I added their repo:


Which was immediately recognised and told me I had a language binding available for F#; but, alas, just as we neared the end of the adventure, it all went wrong. The AddIn was developed for MonoDevelop 2.4 and I'm now running 2.10. Joys of bleeding edge. But fear not! I found the source of the AddIn on GitHub, cloned it and started to get it to build with MonoDevelop 2.10!

git clone https://github.com/fsharp/fsharpbinding.git
I did a couple of tentative fixes:
$ git diff
diff --git a/Makefile.orig b/Makefile.orig
index a88a8a8..0234959 100644
--- a/Makefile.orig
+++ b/Makefile.orig
@@ -57,6 +57,7 @@ FILES = \
src/FSharpResolverProvider.fs
REFERENCES = \
+ -r:$(MONOBIN)/Mono.Posix.dll \
-r:$(MONOBIN)/mscorlib.dll \
-r:System.dll -r:System.Xml.dll \
-r:$(MDBIN)/MonoDevelop.Core.dll \
diff --git a/configure.sh b/configure.sh
index 06f06f5..94f33aa 100755
--- a/configure.sh
+++ b/configure.sh
@@ -83,12 +83,12 @@ searchpaths "MonoDevelop" bin/MonoDevelop.Core.dll PATHS[@]
MDDIR=$RESULT
echo "Successfully found MonoDevelop root directory." $MDDIR
-PATHS=( /usr/lib/fsharp /usr/local/lib/fsharp /opt/mono/lib/mono/2.0 )
+PATHS=( /usr/lib/fsharp /usr/local/lib/fsharp /opt/mono/lib/mono/4.0 )
searchpaths "F#" FSharp.Core.dll PATHS[@]
FSDIR=$RESULT
echo "Successfully found F# root directory." $FSDIR
-PATHS=( /usr/lib/mono/2.0 /Library/Frameworks/Mono.framework/Versions/2.8/lib/mono/2.0 /opt/mono/lib/mono/2.0 )
+PATHS=( /usr/lib/mono/4.0 /Library/Frameworks/Mono.framework/Versions/2.8/lib/mono/2.0 /opt/mono/lib/mono/4.0 )
searchpaths "Mono" mscorlib.dll PATHS[@]
MONODIR=$RESULT
echo "Successfully found Mono root directory." $MONODIR
But finally succumbed to the following error:
./Configure.sh
make
error FS0219: The referenced or default base CLI library 'mscorlib' is binary-incompatible with the referenced F# core library '/usr/lib/fsharp/FSharp.Core.dll'. Consider recompiling the library or making an explicit reference to a version of this library that matches the CLI version you are using.

error FS0218: Unable to read assembly '/usr/lib/fsharp/FSharp.Core.dll'
make: *** [all] Error 1
So it seems I need to get a 4.0 build of FSharp.Core. We'll continue on the next installment!

Sunday, January 01, 2012

Nerd Food: Batch exports using latest org mode

I recently hit an annoying problem with org-mode: batch exports of gnuplot where failing with a mysterious error (full details here). To make a long story short, I was told to upgrade to latest org-mode from git. I followed the instructions on the brilliant org-mode FAQ and got there in no time.

But then it hit me, I needed to provided support for latest org mode in batch mode too! I tend to use default emacs settings in batch mode - well, lets put it this way, I never needed anything else - so I wasn't too sure how to do this. Last thing you need is your batch mode taking 1 minute to bootstrap because its running your full .emacs initialisation. And lord knows cunene ain't getting any smaller.

So after some fumbling I hacked myself a quick export.el that bootstraps a minimal latest org-mode:

(setq dotfiles-dir "~/.emacs.d/lisp")

(setq kill-buffer-query-functions
(remove 'process-kill-buffer-query-function
kill-buffer-query-functions))

(add-to-list 'load-path (concat dotfiles-dir "/other/gnuplot-mode"))
(add-to-list 'load-path (concat dotfiles-dir "/other/org-mode"))
(load-file (concat dotfiles-dir "/other/org-mode/lisp/org-install.el"))

(org-babel-do-load-languages
'org-babel-load-languages
'((emacs-lisp . t)
(sh . t)
(gnuplot . t)
(R . t)))
(setq org-confirm-babel-evaluate nil)

(require 'org-install)
(require 'org)
You may notice the setq kill-buffer-query-functions bit. This was to stop a really annoying message coming from gnuplot:
Buffer "*gnuplot-version*" has a running process; kill it? (yes or no)
Googling didn't reveal any direct solutions to the problem, which is a bit worrying; I wonder if I'm getting this because I'm running latest gnuplot mode. At any rate, I managed to knocked up this hack based on some other process related problem and it made the problem go away. The full incantation for emacs is:
$ /usr/bin/emacs --batch --no-site-file --directory ${org_path}/lisp/ \
--directory ${org_path}/contrib/lisp/ \
--load export.el --visit ${target} --eval '(org-export-as-html-batch)'
Replacing ${org_path} with the path to your git clone of org mode and ${target} with the org file you want to generate HTML for.

Wednesday, October 19, 2011

Nerd Food: C++11 with clang

So, C++11 is finally out! However, we still have to wait for the compilers to catch up. Some compilers are faster than others, however, and clang is certainly one of the fastest of the lot. I've recently set-up a simple trunk environment for clang and found it to be pretty stable - at least for learning purposes - so I decided to share my notes.

I started my wonderings with this post: Compiling llvm, clang and libc++ on Linux.However, I must say I found their approach to be a bit too... hacky... so I adjusted it somewhat. You won't fail to notice the similarities though. For the remainder of the article, I assume you have git, svn, cmake, and all other usual development packages installed; if not, apt-get them before proceeding. I also decided to compile clang using clang stable, for giggles mainly, so I got my hands on the latest clang (2.9) via the usual apt-get means. Without further ado, lets get on with it.

The first thing to do is to checkout the source code. I use git as an svn client, but feel free to use svn directly. Unfortunately, I couldn't get git svn to use modules, so I ended up having to do an svn checkout of clang. Oh well.

Checkout steps:
$ mkdir llvm
$ cd llvm
$ git svn clone -r HEAD http://llvm.org/svn/llvm-project/llvm/trunk llvm_src
$ cd llvm_src/tools
$ svn checkout http://llvm.org/svn/llvm-project/cfe/trunk clang
$ cd ../../
$ git svn clone -r HEAD http://llvm.org/svn/llvm-project/libcxx/trunk libcxx_src
We now have llvm, clang and the standard library. However, before we can do a build we must do the include headers hack:
$ cd llvm_src/tools/clang/lib/Frontend
$ emacs InitHeaderSearch.cpp
"Apply" the following patch, replacing marco with your username:
// FIXME: temporary hack: hard-coded paths.
- AddPath("/usr/local/include", System, true, false, false);
+ AddPath("/home/marco/local/include/c++/v1", System, true, false, false);
Exit emacs. The source is now ready to build. As we are civilised folk, we do out of source builds:
$ cd - # e.g. back at the llvm top level directory
$ mkdir llvm_build
$ cd llvm_build
$ CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=/home/marco/local ../llvm_src -j4
A couple of notes:
  • If you want to do a default gcc build you can omit the CC and CXX variables. If you have multiple gcc versions, just set them accordingly (e.g. CC=gcc-4.5 CXX=g++-4.5, etc.).
  • Ideally you want the install directory to be a throw away directory that you can wipe out whenever, so don't put anything else on it.
  • Feel free to bump the -j4 to a sensible number depending on the cores you have available. If you are not using the machine, a -j6 or even -j8 on a quad-core tends to speed things up a lot.
You can now install clang:
$ make install
This will copy all the libs and binaries over to the install directory (~/local on our case). Now we can build and install the standard library:
$ cd ../libcxx_build
$ CC=clang CXX=clang++ cmake -DCMAKE_INSTALL_PREFIX=/home/marco/local ../libcxx_src -j4
$ make install
At this point you now have a complete, if somewhat bare, clang trunk environment to play with. So lets create a simple program to test it:
$ cd ..
$ mkdir simple_src
$ mkdir simple_build
$ cd simple_src
$ emacs simple.cpp
Type a simple hello world:
#include "iostream" // can't get the angle-brackets to work..
#include "fstream" // can't get the angle-brackets to work..
using namespace std;

int main(int, char**) {
std::cout << "Hello c++11 world!" << std::endl;
return 0;
}
On the same directory, create a trivial CMakeLists.txt file (I'm making it a bit more involved as I have a template...):
cmake_minimum_required(VERSION 2.8 FATAL_ERROR)

project(simple)

#
# compiler and linker flags
#

# enable as many warnings as possible
set(warning_flags "-Wall -Wextra")

# issue all the warnings demanded by strict iso c and iso c++
set(warning_flags "${warning_flags} -pedantic")

# treat warnings as errors
set(warning_flags "${warning_flags} -Werror")

# definition shadows another
set(warning_flags "${warning_flags} -Wshadow")

# do not issue warnings for system headers
set(warning_flags "${warning_flags} -Wno-system-headers")

# overloaded virtual function has a different signature
set(warning_flags "${warning_flags} -Woverloaded-virtual")

# make string constants const char*
set(warning_flags "${warning_flags} -Wwrite-strings")

# enable RTTI
set(other_flags "-frtti")

# set the flags
set(CMAKE_CC_COMPILER /home/marco/local/bin/clang)
set(CMAKE_CXX_COMPILER /home/marco/local/bin/clang++)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -L/home/marco/local/lib")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${optimisation_flags}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${warning_flags}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${profiling_flags}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${other_flags}")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -nostdinc++")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")

set(app "simple")

set(files "")
file(GLOB_RECURSE files RELATIVE
"${CMAKE_CURRENT_SOURCE_DIR}/"
"${CMAKE_CURRENT_SOURCE_DIR}/*.cpp")

add_executable(${app} ${files})
We can now compile our test program! Exit emacs and type:
$ cd ..
$ cd simple_build
$ cmake ../simple_src
$ make
To run the binary we will need to ensure the C++ library is on the program loader's path:
$ LD_LIBRARY_PATH=/home/marco/local/lib ./simple
Hello c++11 world!
One interesting thing to notice is that we still have two C++ libraries:
$ LD_LIBRARY_PATH=/home/marco/local/lib ldd simple | grep c++
libc++.so.1 => /home/marco/local/lib/libc++.so.1 (0x00007fa5b5188000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fa5b463f000)
Something for a further article though.

With this set-up you can now follow clang trunk development; just git svn rebase, and svn update all the checkout directories, rebuild and re-install. Every so often you may need to delete the whole of ~/local and start again, but other than that you should be good to go.

Tuesday, August 02, 2011

Nerd Food: No sound with flash

Life on the debian testing lane is never boring. After loosing X.org for a week - its fine now, thanks! - I found myself without sound on flash. The fix was simple: /etc/asound.conf was gone, for some reason. As root, I created it again with the following content:
pcm.pulse {
type pulse
}
ctl.pulse {
type pulse
}
pcm.!default {
type pulse
}
ctl.!default {
type pulse
}
Solution courtesy of the Ubuntu wiki.