Category Archives: Programming

Responding to search terms

Got a few good search terms to respond to again, so here goes:

twiki install centos 5.1: Don’t do it unless you know what you’re getting into. I had a bad security experience likely caused by Twiki, and I’ve seen a lot of people reporting similar experiences that they are convinced was Twiki’s fault. At the very least, google “twiki security” before you do it. The codebase is much too large for a single person to audit it in a reasonable amount of time. If you need a good Wiki in general, give Moin a try. Consider using a Wiki hosting service, where someone else has to worry about the security of the underlying machine. Or just don’t use a Wiki at all — unless you truly want what a Wiki in specific has to offer.

iphone unofficial toolchain easiest way: There is no easy way. There is drudge’s way that I point to in another entry, but aside from that I didn’t find any way that was at all easy. binutils can be convinced to generate (possibly-working) tools for arm-apple-darwin fairly easily, but I think GCC is a bit trickier. Don’t try to do it on your own unless you want to spend a lot of time making the tools work rather than using them.

do peanuts have gluten?: Nope, peanuts don’t have gluten in them. They may have gluten on them, though — it depends on how they’ve been processed or flavoured. When in doubt, read the label and assume that “spices” includes something gluten-based. I’ve seen some with and some without gluten, so have a look around.


64-bitness is a problem with the iPhone SDK

According to the iPhone SDK ReadMe, the beta version of the SDK isn’t exactly ready to go on 64-bit systems. Given that I’m using a 64-bit system this may explain Error 34 and some of the other strangeness I encountered.

I’m also running into walls left, right, and centre in my plan to get GCC running on the iPod Touch. I had also forgotten about Perl‘s perverse configuration process, which doesn’t lend itself easily to cross-compiling.

At this point I think I’m going to punt on building Perl for the iPod until the official SDK is released and I can get on the developer program. The fact that this will almost certainly take several months (until Apple is ready to accept non-Americans) is annoying to me, but there’s naught that can be done about it — I simply don’t have the knowledge to port GCC to the iPod, and that seems to be the most sane way to get these things going.

A few more packages

I managed to get a few more packages put together, and they’re available at with the first few. I’m at the point now where I can likely get start looking at gcc‘s specific dependencies.

strndup on arm-apple-darwin

I’m trying to build bison for arm-apple-darwin and I’m running into a bit of trouble that looks like it originates in autoconf and/or friends. As configure runs, it checks for strndup to be declared and for it to be usable, and it claims it’s not declared but it is usable. The build fails with an unresolved symbol _strndup. The even odder part is that there is an implementation of strndup in the lib library, and it seems to get linked into libbison.a, but nm shows the symbol as being unresolved. This is probably due to some preprocessor magic going on in the implementation file.

Is there anyone out there who knows a bit about autoconf or how bison (or similar projects) fit together who can give me some clue as to what’s going on? I’m a total autotools newbie.

I’ll see what other deps I can pull together in the meantime.

The first few packages

I’ve started to build a few packages that will help me build Perl building on the iPod Touch. Rather than try to cross-compile Perl, I’ve decided to cross-compile what I need to get a development environment going on the iPod itself. It means much longer builds but much quicker total development time — or at least that’s what I’m hoping for.

So far I’ve got flex 2.5.35, libiconv 1.12, libtool 2.2, and m4 1.4.10. They’ve all been pretty easy, with the only hiccup coming when the flex build #defined malloc to rpl_malloc, apparently because the autoconf macros AC_FUNC_MALLOC and AC_FUNC_REALLOC set that up if they detect functions that aren’t GNU-compatible. Unfortunately, there’s no implementation of rpl_malloc or rpl_realloc available, so the build died when the symbols couldn’t be found in the libraries.

For the moment I’m just keeping shell scripts that patch files (where necessary) and run configure with the appropriate arguments. I’ll throw them up on my website tomorrow when I get a chance. I’ll update this entry with the link. If anyone has any advice moving forward I’d love to hear it — especially if I’m going about things the wrong way. I just have no clue when it comes to autoconf and friends.

Update: The first packages are up at More will be on the way.

A working iPhone/iPod Touch toolchain on Leopard

After realising that the iPhone/iPod Touch SDK isn’t going to do what I want it to do yet, I am experimenting with various ways of doing what I actually want to do — run programs on my iPod Touch, not a simulator.

My first try is drudge’s HOWTO build the toolchain on Leopard, and it looks good so far, which is to say that I’ve got “hello world” running on my iPod. It seems to include everything you’d need.

The next big question is how to package things up for installation onto the device. For now I’m going to assume that people can scp things to their device and ssh into it (or use a terminal) to do the installation. I will likely get the Installer packages built eventually, though.

“Hello world” to bus error in no time flat

Using xcodebuild I figured out the command line to build a simple “hello world” in C for the ARMv6 in my iPod Touch. After scping it into place it faulted on me with a bus error. I don’t know off-hand if the ARMv6 can actually raise a bus error, or whether that particular error is overridden to actually mean something else entirely.

I also have no way of figuring out if the executable is able to find its shared libraries, as otool is conspicuously absent on the iPod, and I don’t know how to check out ARM binaries on my Macbook. My guess at this point is that the Aspen 1.2 SDK will only generate executables for OS 1.2 and higher, so 1.1.3 won’t work.