Modifying Gummiboot Configuration

Modifying gummiboot configuration (at least in Arch Linux) is quite easy. Upon gummiboot execution (when boot menu is displayed), you can press h to show the gummiboot configuration "help" as shown below.

The screen shot above shows the gummiboot help menu in the lower center of my laptop display. These are the key bindings:

• d (lower case) sets the currently highlighted menu entry as the default boot OS (or UEFI application) on boot.
• h (lower case) shows the help menu in the bottom part of the display. Just like shown in the screen shot above.
• t (lower case) increments the timeout to execute the default boot menu.
• T (upper case) decrements the timeout to execute the default boot menu.
• p (lower case) prints "something?". I haven't test what "print" exactly means here.

Therefore, to change the default OS/UEFI application to be automatically executed on timeout, you just need to select the menu entry you want and then press d in gummiboot. The newly set default menu should be effective immediately and preserved upon reboot/shutdown. Anyway, this post is further elaboration from: Modifying Gummiboot Configuration.

Cross-Compiling Raspberry Pi Application from Windows with CodeBlocks

Let's start with problem definition: Raspberry Pi is too slow for most complex software compilation/build process. Therefore, we need something much more powerful. "Unfortunately" for me, I'm left with a Windows 8.1 Professional machine due to my day job with Micro$oft stuff as that something much more powerful. But, never mind, there's a solution for that platform problem. My machine is quite powerful, a Core i5 4200U (2.xx GHz @turboboost) with an 8GB RAM.

Anyway, there's a quite mature GNU Toolchain for this cross compilation task, kindly provided by Sysprogs: http://gnutoolchains.com/raspberry/. It even comes with the tutorial to use it: http://gnutoolchains.com/raspberry/tutorial/. However, it doesn't explain how to use the cross toolchain in CodeBlocks because it expect you to use Visual Studio. Well, Visual Studio is just way too resource hungry for my taste. Therefore, let's find out how to use the cross toolchain with CodeBlocks.

Footnote:
-------------
- This post is incomplete. However, I decided to post it as it could help as starting point for those really looking into doing this kind of thing. I've left Windows for about a year now. Therefore, this has no relevance to me as of now.

Building Memcached with Statically-Linked Libevent

Building memcached with statically-linked libevent is not quite complicated. However, I found out that we have to make slight adjustment to memcached build system and header. In some scenario, statically linking memcached to libevent is the preferred solution in order to remove the headache associated with maintaining different versions of memcached-libevent combination.

Well, actually, I have a working combination of memcached 1.4.24 and libevent 2.0.22-stable. But, it's very dirty at the moment. I'll eventually release it in Github.

Anyway, these are what you need to do to make memcached linked into statically built libevent:

1. Place libevent source code inside memcached root directory (the next steps assumes you placed libevent source code inside memcached root directory).
2. Make the libevent code statically built by using LT_INIT([disable-shared]) in its configure.ac
3. Make memcached only link to libevent_core.la in memcached Makefile.am. Nothing more than that, because that's all it needs.
4. Add AC_CONFIG_SUBDIRS([your_libevent_dir]) to memcached configure.ac. 
5. Disable/remove support for dynamically-linked libevent from memcached configure.ac. 
6. In my particular memcached version, I need to modify memcached.h to add two additional libevent include files to make it compile-able, i.e. event_struct.h and event_compat.h. 

Hopefully, this is enough as hints for those wanting to statically link libevent to memcached. I'll update this post once the code is up in GitHub.