A few more packages

I managed to get a few more packages put together, and they’re available at https://www.kjwcode.com/project/idev/ 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 https://www.kjwcode.com/project/idev/. 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.

Possible explanation for Error 34

It occurred to me as I was reading through some iPhone/iPod Touch SDK information today that the whole SDK is geared towards iPhone OS 2.0 — Error 34 may be the Organizer’s way of complaining that the device isn’t running the expected OS.

If this is true, it’s something of a kick in the teeth. I’m sure I’m not the only person who was expecting to be given an SDK that was immediately usable on my device. I trust that a lot of experimentation by a lot of people will turn up some goodies, but for now I’m guessing that I’ll have to wait to use the official SDK. There is the off chance that code that doesn’t touch the UI or specific features of the device will still work — perhaps well enough to port Perl or similar. I’ll be experimenting with that this weekend.

Error 34 — first frustration

So I got the iPhone/iPod Touch SDK downloaded and installed. Getting a sample app to run in the iPhone emulator is easy enough, but I can’t get it to run on my iPod Touch. There are two things I see getting in my way.

The first is that when I try to add an application to the iPod in the Organizer I get a message to the effect of “your mobile device has encountered an error” and the dialog specifies error code 34. I have no idea what this means yet, but I have a sinking feeling that it will only work with an iPhone, and not an iPod.

The second is that when I try to build the project for Aspen (as opposed to Aspen simulator) I get an error at the last minute about not having a code signing key. This I somewhat expected, but I also thought I should at least be able to put applications on my own device without having one. Typically, Apple is only allowing Americans to have code signing keys at this point, though they say that other countries’ developers will be included “in coming months”.

I’m feeling somewhat foolish for un-jailbreaking my iPod at this point. My only comfort at this point is that I’m not the only person struggling with it.

Update: The likely reason for this error is that the SDK builds code for OS 2.0.

Update: This seems even more likely, since programs built with the Apple SDK give bus errors when run on a device.

Update: If you want to get started building code that runs on a real device instead of the Aspen simulator, build a toolchain that will do the trick.