Common issues when porting applications to avr32

Cross-Compilation

In case you port a simple application: Be sure to CROSS-CPOMPILE!
Ususally this can simply be done by saying "make CC=avr32-linux-gcc all".

autoconf-related issues

Although autoconf is a tool that's supposed to make it easier to write portable programs, we're not living in a perfect world. Especially when cross-compiling (which, admittedly, is not a very common usage) problems tend to show up.

Often you will have to disable e.g. x (--disable-x) or specify PKG_CONFIG_PATH or both, in addition to package-specific options. The most common problem is broken or uncomplete/lazy configure scripts that finds wrong libraries or does not find libraries at all. Alter the configure script and Makefiles if necessary! Optimization flags like -O3 is still known to be unsafe, try compiling with -O2 if you get unexpected errors.

Variadic arguments

This error is not discovered while compiling to i386 architecture because of the way the arguments and varargs are passed to functions. This gives a runtime error on the AVR32, often with a SIGSEV(segmentation fault) message.An example is given below:

The function Construct is of type:

 typedef DirectResult (*DirectInterfaceGenericConstructFunc)( void *interface, ... ); 

The (erroneus) implementation of the function looks like this:

 static DFBResult Construct( IDirectFBImageProvider *thiz, IDirectFBDataBuffer *buffer )

where the second argument is not a vararg. The solution is to #include and get the variadic arguments the right way.

Short enums

The version of gcc shipped with Atmel's STK1000 BSP version 1.0 uses short enums by default. Short enums are just big enough to fit all the enumeration values, which means that all enums aren't of equal size. This causes problems with (broken) programs that assume all enums are equal, or even worse, that enums have the same size as int.

Newer versions of avr32 gcc will most likely change this so that enums and ints can be used interchangeably.