Friday, December 31, 2010

TianoCore and coreboot, again

It has been over two years since the last time I worked on TianoCore for coreboot. These days I had some free time to spend and I used it to continue the project. I updated my code to the latest versions of coreboot and TianoCore and got it to work again in QEMU.

Here's a "screenshot" and a few words on what it's all about.

Tuesday, October 19, 2010

ImageMagick, libjpeg, etc. on Mac OS X

Here's how I got ImageMagick with JPEG support to compile and run on Mac OS X 10.6 (Intel).

First, I got the ImageMagick Source Code via Subversion, per the instructions from http://www.imagemagick.org/script/subversion.php. Short version:
$ svn co \ 
https://www.imagemagick.org/subversion/ImageMagick/branches/ImageMagick-6.6.5 \ 
ImageMagick-6.6.5
Then, I pulled libjpeg from the Independent JPEG Group. I had to extract the source code to a subdirectory of the ImageMagick directory called jpeg, i.e. /path/to/ImageMagick-6.6.5/jpeg.

Before I could compile any of the source code, I had to set three environment variables per this thread on the ImageMagick forums:
$  export CFLAGS="-isysroot /Developer/SDKs/MacOSX10.6.sdk \
  -arch ppc -arch i386"
$ export CXXFLAGS="-isysroot /Developer/SDKs/MacOSX10.6.sdk \
  -arch ppc -arch i386"
$  export LDFLAGS="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk \
  -arch ppc -arch i386"
Then, I compiled libjpeg via the via the standard ./configure and make dance. I used these commands:
$ cd jpeg
$ ./configure --prefix=/opt --disable-shared \
  --disable-dependency-tracking
$ make -j 16
Now, I was able to configure ImageMagick:


Be aware that the LDFLAGS path is different than the include path! If everything went well, you can now go on to build the imagemagick suite:

$ ./configure --prefix=/opt --without-x --without-perl --with-jpeg \
   --disable-shared --disable-dependency-tracking \
   --enable-delegate-build --enable-osx-universal-binary
$ make -j 16
This gave me statically linked binaries of the ImageMagick tools I was able to run on my Mac. I also tried to build dynamically linked binaries but failed. Because I don't need the dynamically linked version, I gave up after a while.

Friday, September 24, 2010

Testing with Google's C++ Test Framework (gtest)

The other day I was playing around with Google's C++ Testing Framework (a.k.a. gtest). I tried to build the Code with Visual Studio 2008 Express and got some strange linker errors. I was able to solve the errors thanks to this site. In essence, I had to change the "Runtime Library" Setting in the C/C++ Code Generation options to "Multi-Threaded" for a release build and to "Multi-Threaded Debug" for a debug build.

Wednesday, August 25, 2010

Linker Sets

Reminder: When placing something in a dedicated section using __attribute__((section("foobar"))), the GNU toolchain will automatically add a symbol __start_foobar at the beginning and a symbol __stop_foobar at the end of the section.

However, you will need a reference to that symbol in order to prevent the linker from optimizing the symbol away. In other words, you need to declare something like extern void *__start_foobar; and use it.

When using the Microsoft toolchain, the symbols need to be added explicitly. To do that, one can make use of the fact that when the Microsoft linker encounters several sections with a "$_" in their name, it will merge the contents into one final output section. The name of the output section will be the common prefix of the declared sections. The beauty is that the contents are in the order of the section names.

Here's an example: Supposed you placed something into a section called "foobar$_something". You can then add a variable __start_foobar into a section "foobar$_a" and a variable __stop_foobar into a section "foobar$_z". The resulting binary will have one section "foobar" with the contents of variable __start_foobar placed at the beginning, followed the contents of everything in section "foobar$_something" and the contents of the variable __stop_foobar at the end.

Monday, March 22, 2010

Fix Windows Full Text search

I've recently noticed that using the Windows full text search may not always turn up the expected results. Apparently, Windows requires a program to install a search filter for a given file type. There is some plain text filter available by default, but it's only registered for some endings. Source code files, e.g. Groovy files, will not be included, even though they contain nothing but plain ASCII text. Anyways, there's a fix available, but it's nowhere near intuitive...