Saturday, July 25, 2015

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.

Sunday, July 12, 2015

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.

Thursday, July 9, 2015

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.

Thursday, April 16, 2015

Illegal Instruction in IBM iSeries (AS400) PASE

Perhaps, most of those who had develop application(s) in iSeries PASE have encountered this very irritating error: "illegal instruction .. bla bla bla .." . Usually, the error shows up at runtime, not when compiling code on PASE. I was very confused back then too. However, upon closer inspection I found out that the culprit is mostly down to this fact:
  • An operating system API defined in AIX also present in iSeries PASE header files.
  • PASE doesn't implement the said API. However, due to  the presence of unaltered AIX header in PASE, the compiler doesn't complain.
  • At runtime, the runtime loader (and "linker") complained that the said API doesn't exist in the OS. This is the source of said "illegal instruction .. bla bla bla .." error.
I have to give credit (sic) to IBM that the error made me nervous back then as I thought the compiler I used + IBM supplied linker "combination" created wrong binary which causes the illegal instruction to be emitted upon linking. Only upon closer inspection that I found the culprit explained above. 

Maybe, you want to ask me: then how the hell am I going to be sure the API I needed is supported or not?
Well, you can consult IBM Redbooks. But, AFAIK, you have to test your binary to be 100% sure because there's no detailed explanation on which API are supported and which are not for recent iSeries OS versions (>= iSeries v5.3).