Missing extern "C"

I'm sure most of us hit the problem of that annoying linker error "unresolved external symbol "aoein0hepqo2washpeofh a@foo" (ok, I just hammered the keyboard - it's no real live symbol name!).
After triple-checking the library link list it turns out that (again) the mixing of C and C++ modules and libraries is the root of the problem.

But what to do if you have a C++ module that references an API function declared in a header file that is not prepared to be included by C++ code?

If you are not allowed to patch the file (may be its 3rd party stuff) there is a quite simple solution:

extern "C"
{
#include
}

Cheers,
Jürgen
Read more! Post this to a friend!

Use previous Windows Embedded CE 6.0 Rx install for your next project

Using your previous Windows Embedded CE 6.0 Rx install for your next project should actually be a valid use case. But as a feedback from yesterdays post in this blog I got a phone call from one of my colleagues asking: "Look: Half of my development team has build problems after installing the new BSP in our new project. Any idea?"

I remembered the Peanuts comics, smiled and said: "The doctor is in! So tell me..."

Doing a blddemo -q build errors occur stating error C2677: Undefined assembler operation. The current build directory is c:\wince600\platform\common\src\soc\....blabla...

So what's happening here?

error C2677 is a MIPS Error Message. The directory above is listing the SOC (System On Chip) designs supported by all installed BSPs. Inside that directory we identified BSP support for various SOCs. These causing the problems and used in previous projects were Freescale's iMX27, iMX31, and iMX35. And these are non MIPS but ARM core SOC designs. And surely the selected MIPS assembler does not know how to handle ARM assembler operations.

So I suggested to deinstall these iMX BSPs which would surely solve the build problem. But that's not a valid solution if you still have to support the old project.

2nd proposal is to introduce some logic checking an environment variable defining the CPU or SOC (TGTCPU) selected for the current build in the C:\WINCE600\PLATFORM\COMMON\SRC\SOC\dirs until now stating to traverse all subdirectories (DIRS=*). But that's most likely causing maintenance issues on this file for upcoming BSP installs or removals that have to be solved manually even if these BSPs do not have the drawbacks from Freescales BSPs mentioned.

So how and where do other BSPs control if they are MIPS or ARM or whatever?

Well, directly in the sources files inside the subdirectories below C:\WINCE600\PLATFORM\COMMON\SRC\SOC\. Inside these sources files you can use NOMIPS16CODE=1 or identify ARM assembler sources by ARM_SOURCES= foobar.s ...

So you can add this type of control where needed in the sources files of the iMX BSPs coming from Freescale. Surprisingly this takes just a few minor changes.

Surely it would be nice if Freescale would solve these build issues directly in their BSPs to improve such compatibility issues in multi platform scenarios with different target CPU cores.

So much for project hopping from Freescale iMX (ARM core) to MIPS II FP. You mean I have not explained how this is solved in x86 or SH? Correct! I haven't... But there always has to be some magic left over. Especially at this time of the year...

-- Oliver Merkel

"Christmas waves a magic wand over this world, and behold, everything is softer and more beautiful." --N. V. Peale


Read more! Post this to a friend!

CommCtrl with R3 Touch broken after QFE update (Fatal error U1077)

A while ago Jochen already posted some info on Touch Gestures feature introduced in R3. So if this is coming along with Windows CE 6.0 R3 then there must be a situation to mess up things from R2 and R3.

And here it is:

Get the R3 iso image from Microsoft download center. Nearly 1.2 GB of data. But at least if that stuff in your installation gets broken you get all data to do a repair then.

Run R3 update being an incremental install to an existing Windows CE 6.0 R2 and voilá: It's working.

Now we learned one thing: Update everything to have the latest changes available! So get the QFEs!

But be aware: This might break your R3 install. If you have already done so then each blddemo will run into the following situation. Your build.log will show a fatal error:

commctrl.lib(aygutils.obj) : warning LNK4217: locally defined symbol SHCreateDefaultGradient imported in function "public: static int __cdecl AygUtils_t::SHGradientInit(struct tagSHGRADIENT *,int,unsigned short const *)" (?SHGradientInit@AygUtils_t@@SAHPAUtagSHGRADIENT@@HPBG@Z)
commctrl.lib(aygutils.obj) : warning LNK4217: locally defined symbol SHGetSystemMetrics imported in function "public: static int __cdecl AygUtils_t::SHGradientInit(struct tagSHGRADIENT *,int,unsigned short const *)" (?SHGradientInit@AygUtils_t@@SAHPAUtagSHGRADIENT@@HPBG@Z)
commctrl.lib(lvgesture.obj) : error LNK2019: unresolved external symbol "public: static void __cdecl TouchPerf::ReleaseSession(void)" (?ReleaseSession@TouchPerf@@SAXXZ) referenced in function "public: __cdecl GestureTriggeredScrollCtrl::~GestureTriggeredScrollCtrl(void)" (??1GestureTriggeredScrollCtrl@@QAA@XZ)
commctrl.lib(lvgesture.obj) : error LNK2019: unresolved external symbol "public: static void __cdecl TouchPerf::AcquireSession(void)" (?AcquireSession@TouchPerf@@SAXXZ) referenced in function "public: __cdecl GestureTriggeredScrollCtrl::GestureTriggeredScrollCtrl(void)" (??0GestureTriggeredScrollCtrl@@QAA@XZ)
C:\WinCE600\OSDesigns\???_MIPSII_FP\cesysgen\oak\target\MIPSII_FP\debug\commctrl.dll : fatal error LNK1120: 2 unresolved externals
NMAKE : fatal error U1077: 'link' : return code '0x460'
Stop.
NMAKE : fatal error U1077: 'C:\WINCE600\sdk\bin\i386\nmake.exe' : return code '0x2'
Stop.

This one can not be resolved with turning on/off catalog item selections or something like that. The current QFEs simply break your R3 install and overwrite some files but not all being related to Touch Gesture or other R3 features.

This will most likely be fixed in the upcoming QFEs again but meanwhile just re-run the R3 rollout msi (Microsoft Installer) included in the ISO image and select repair from the corresponding menu.

Until now I did not encounter any side effects after using this R3 repair.

Unfortunately it's hard to say if the R2 tree is completely merged in R3 or if some side effect might occur. If I find some time I will check that. But most likely best way is to wait for the next QFEs to get that properly fixed.

At least the repair will allow you to continue work on R3 development that way.

Merry Christmas and Best Wishes for a happy new year, and all your R2 and R3 projects...

--- Oliver
Read more! Post this to a friend!

Switching target OS from project to project

Ho ho ho and joyous Season Greetings,

from time to time I come across the situation to help out in projects with different Operating Systems. And guess what... sometimes one of the Operating Systems is a Microsoft Windows CE / Windows Mobile / MS Auto etc. Now assume that first such a switch of the target OS from one project to the other is happening and that second it is most likely that both Operating Systems are mainly developed in C/C++.

So we have compilers, linkers and other parts of the tool chain including make tool, etc. Thus we all (including you) run into issues that the environment variables of the development host have most likely the same naming even if we switch the compilers, linkers, etc.

You probably just came across such a situation if e.g. the Visual Studio Platform Builder Plugin for Windows CE 6.0 Rx behaves like that:

Starting Build: blddemo -q

Some output in Build Output window during sysgen phase but less than expected... There were build errors and build.log just says

Starting sysgen phase for project ( common )
Found localized resources for Languages ( 0404 0407 0409 040C 0410 0411 0412 0413 0416 0419 041D 0804 0C0A)

Microsoft (R) Program Maintenance Utility Version CE-6.00.1893.0
Copyright (C) Microsoft Corporation. All rights reserved.

NMAKE : fatal error U1065: invalid option '-'
Windows CE Version (Release) (Built on Jun 30 2006 16:52:46)
Stop.

So what can possibly go wrong at that early build phase? If this is correlated to the same reason I am thinking of then this will happen in all your BSP building solutions yet.

The failure results from an nmake sysgen invoked in C:\WINCE600\PUBLIC\COMMON\CESYSGEN. Having a short look into the makefile reveals that from included cesysgen.mak the rules preproc and postproc described in makefile should be executed.

But where's this !"§$ option of that nmake error message above coming from? You never set that option?

On build console (build window) do a set MAKE. Probably you get something like:

MAKEFLAGS=-Id:/??????/target/????/usr/include

This could have been set up by other build environments and is normally or most likely not used in a Windows CE / Windows Mobile environment. If you clearly identify this to belong to some other target operating system than Windows CE / Windows Mobile and it is not used right now then remove this environment variable and run your build command again.

set MAKEFLAGS=
blddemo -q

This is most likely doing the trick...

To wish you the special gifts of this holiday season - Peace, Joy, Lasting Happiness and a working tool chain to build your favorite OS.

-- Oliver
Read more! Post this to a friend!