During last couple of weeks, I made the immigration of building Mozilla NSPR component with Carbide.C++ (still based on makemake and friends Perl scripts) to GNU make and autoconf friends. Here I will share some points I learned in this process.

First of all, if your open source project uses a lot of Writable Static Data (WSD), in theory even only one single variable, and they are used in dynamically linked library (DLL) target type, then your only choice is buying a RVCT compiler. Because GCCE compiler which ships with the S60 SDK has a defect that can not build a working DLL binary if there is WSD in it. This known bug is documented by Symbian already. Though in the document Symbian stated the problem is solved in a later GCCE release possibly, yet I had tried all GCCE releases which is later than 2005Q1C, then found some of them will generate an internal compiler error and some of them build the same defective binary almost the same as 2005Q1C. So I think I could give you the advice : try only GCCE compiler tools if it is shipped with Nokia or Symbian, otherwise you are spending your time on what has been proven already.

Then let's get back to the build tool chain immigration affair. Actually I observed all original makmake build process in Carbide.C++, and then try to copy all compiler and linker arguments to GNU make Makefile scripts. The work is not so hard, and the result is also convenient to verify. Here are some brief points need your attention:

• Compiler/linker arguments are main additions feed to Makefile
• Emulator builds and target device builds use different compiler/linker
• Device builds will need post linker operations, elf2e32 is the tool we use
• ActivePerl is used to calling the .RSS resource file compiling, other Perl probably won't work
• Building statically linked library (.LIB target type) takes no post linker jobs to do, compared with .DLL and .EXE

Cheers~