[Nokia Ron]

Hello,

Nokia would appreciate it if you could share your perspective on what some of the key issues/concerns you may have when porting their applications natively to S60 3rd edition.

Thanks for any feedback to help us improve porting especially with hand-held devices to Symbian native.

Ron

[mgroeber9110]

Originally Posted by Nokia Ron

Nokia would appreciate it if you could share your perspective on what some of the key issues/concerns you may have when porting their applications natively to S60 3rd edition.

When working with portable code in complex projects involving Symbian I have always noticed the rather isolated nature of the Symbian toolchain. Often, when porting existing projects these system already come with a more or less elaborate build environment of their own - i.e. a "valuable" port usually does not just consist of dozens of C files that have to be compiled "somehow", but also the dependencies between them, and the relationship to code for other platforms.

However, the Symbian "bldmake/abld" toolchain is a fairly closed environment - as long as you are willing to write and maintain .mmp files for your entire project, everything is fine. But if you have existing makefiles or build scripts (sometimes hundreds of them), integration of bldmake/abld into such an existing environment is very tricky.

Generally, I have tried two ways to handle that:

1. Write a parallel set of .mmp files, and invoke bldmake/abld - this hides most of the Symbian toolchain, but requires maintaining the .mmp files separately, and makes it difficult to handle the build results because the deliverables are just dropped somewhere in the SDK directory. Even detecting build errors is a problem because abld does not return error codes. All of this can be worked around with sufficient amounts of Ruby or Perl, but the results tend to remain half-baked...

2. Reverse-engineer the makefiles generated by "abld makefile" to get the exact commandlines for compiling and linking Symbian code, and then integrate them into multi-platform makefiles. This often allows re-using one's own build system, but causes problems e.g. with new SDK versions - how to locate the SDK directory, the various tools etc.

So my request for making complex ports easier is to consider formally documenting the "core" tool chain (rather than encoding the knowledge inside makmake), and isolating it somewhat from the Symbian build system - always remembering the fact that people doing ports may not start from a hand-written .mmp and three source files...

For example, this could be well-documented gcc and mwcc option lists that describe which #defines and compiler options are strictly required for Symbian compatibility. Also, a standardized set of Registry keys and/or environment variables set by each SDK to allow easy locating of the build tools would go a long way...

I sometimes wonder how Symbian and Nokia actually automate *their* builds...

[billbonney]

Here's some suggestions

- Use Extension Makefiles in bld.inf to have the symbian toolchain call your build steps that need to use. see Symbian OS v9.1 » Symbian OS Tools And Utilities » Build tools reference » bld.inf file syntax » Extension makefiles see http://www.symbian.com/developer/tec...Makefiles.html

- Have a look at genbuild for building more than one program at a time http://www.newlc.com/GenBuild-to-Bui...-Programs.html

Hope that helps :)

[grant_j]

Our problem is similar and is not helped by bundling calls to the abld tools together -- we build to multiple platforms, not just different Symbian versions and platforms, using a common code base and a gnu Makefile into which we incorporate calls to the Symbian-supplied compilers and linkers.

So far (i.e. over the last 6-7 years, supporting OS v6.0 - 8.1a) we have had to reverse engineer the makefiles generated by the bldmake/abld toolchain or, in more extreme cases, rewrite some of the Symbian build tools supplied as perl scripts and embed these into our perl scripts to do things like create .def files.

It would indeed be nice to have some independent documentation of the Symbian-specific flags and macros and their effects.

Equally helpful would be some cross-referencing within such master documents as the "S60 2nd/3rd Edition: Differences in Features" -- a specific example being 4.5.8 on p.29 of that document, where it informs me that Avkon.mbm has been removed. After considerable searching, I discovered that Avkon2.mbm exists, but nowhere does it suggest that the new(?) file might substitute for the old, nor is there an example of its use...in fact, the sample applications that include a "wait note" aka progress bar dialog makes no reference to any "image file" at all in their resource file where Avkon.mbm would formerly have been specified, and I am still searching for an explanation.

I understand that the "Difference in Features" document was meant simply as a list of alerts to developers, and not a how-to, but perhaps it could include a link to a how-to or a code example or to the system docs that helps explain the significance of the changes?

Thanks for listening.

[mgroeber9110]

Two more specific points that I noticed in recent porting projects - these are not fully confirmed yet, but they seem to be significant enough to be worth noting, in the hope that someone else can fill in some of the blanks...

• There seem to be some issues (which I don't fully understand...) around using "accidental" Writable Static Data in DLLs specifically with GCCE on 3rd Edition - in prior versions of the platform, this would usually just cause linking to fail because of "initialized static data"; however, in GCCE we have noticed situations where code with WSD and pointers (e.g. a missing "const" in an initialized structure definition) would link fine, but then produces incorrect results at runtime, if built as a DLL.
• Something that can cause errors on the emulator that are very hard to debug is the fact that MSL_ALL_MSE_Symbian_D.lib (the Symbian support library for Code Warrior) contains its own implementations of malloc, calloc, realloc, free, as well as some other C runtime functions. In some circumstances, it can happen that the MWCC versions are used, rather than their counterparts in ESTLIB. I just debugged a project where malloc() would be resolved from ESTLIB, while realloc() would use the corresponding Code Warrior implementation - of course leading to very confusing memory errors, since the heap layout is different between the two libraries, and realloc() would, for example, fail to change the block size for no apparent reason.

Both of these can potentially take days to debug for each occurence, because they are completely non-obvious unless you start looking below the surface of the C++ language. Also, these both come from the class of "subtle differences between emulator and device" problem, which are about the hardest type of problem to debug.

I suspect that these can still occur in Carbidge, because the underlying compiler engines haven't really changed. Especially for the second type of error, I would really hope that Nokia could update the runtime libraries to remove all symbols that are also present in ESTLIB, to prevent accidental inclusion.