Ok so I found the cause of the problem and I'm not sure if I should be embarrassed or not.

I'm using proftpd on my target platform (angstrom) and FileZilla on my dev platform (ubuntu) so I can easily transfer the build outputs to target. I've been transferring executable files like this for weeks now with no problems at all.

The transfer mode was set to auto, rather than explicit ascii or binary modes so I'm guessing this means it tries to work out which mode is best.
Anyway, long story short, the auto mode decided ascii was the mode for the job and subsequently mangled my app behind my back. When set to explicit binary mode it started working again.

Sorry for wasting everyone's time but I hope I can be forgiven for not first investigating something which has been working fine for weeks and not changed in any way.

As a note to anyone who may experience something similar, ftp ascii mode can transfer executable files in some cases (if you're lucky as I was), but generally will mess up the file since it tries to convert \r\n's (windows-style) to \n's (unix-style).
I think the only reason my transfers worked initially was because my binary files contained no \r\n bit patterns (as luck would have it, because it was a small file), then the inevitable happened and my binaries contained the pattern; regardless you should always use binary mode when transferring anything other than plain ascii text and I wouldn't rely on any auto mode; it's not difficult to manually choose ascii or binary.

You should be firstly very clear with why segmentation faults occurs. It can occur due to memory leaks, insufficient memory and other memory related issues.

I wish I knew how to be clear why the fault occured: The problem seems to occur in libperl.a and I stronlgly suspect it's when it calls perl_alloc().

I'll initially rule out memory leaks since my test app currently does nothing other than instantiate and invoke perl.

Insufficient memory strikes a chord. I currently have a 2GB micro SD card which was initially pretty empty when I successfully ran my app. Since then I installed loads of things and almost filled the SD card (I have about 200MB left), so I certainly have much less disk space now than I had before.

My confusion is this: I am low on disk space, not ram. As far as I know perl_alloc() requires ram and not SD card space so I can't see how low SD card space would cause a problem.
I ran 'top' to see if any other processes were hogging ram but almost all of the ram seems to be available.
I do think you're onto something here with the hole "freeing up space" but I don't understand why. Besides, 200MB is still a lot of disk space for one app.

I can't delete much on the SD card, plus I'm afraid of deleting the wrong thing. As a stab in the dark, I'll go get a 16GB card from the supermarket and try again. Is this what you had in mind or did you mean freeing up memory some other way?

I currently have no other platform to test the built app with so can't currently run anywhere else.

Yes I can do the other things you suggested however with my platform (angstrom on arm7), these things take a very long time so I was hoping to resort to this level of diagnostics as a last resort. The fact that this was working makes me think the perl installation and embedded perl app are fine, it's the system which has changed somehow.

Hold that thought ;-)

Do you have any segfault-related messages in the kernel log?
Sorry if my advice was wrong.