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!