Error after Enabling Float Point Hardware (vfp)...

Dec 25, 2009 at 12:10 PM

So I added in the arm vfp as a subproject and I added the catalog item OEM Floating Point CRT (ARM only) and ensured SYSGEN_OEM_FPCRT was set to 1. Everything builds fine, but when making the sysgen, I get the following errors:

Error: Unresolved external: FPCRT
Error: Can't find import 2029 in coredll.dll
Error: Fatal import error in filesys.dll
Error: Unresolved external: FPCRT
Error: Can't find import 2027 in coredll.dll
Error: Fatal import error in filesys.dll
Error: Unresolved external: FPCRT
Error: Can't find import 2032 in coredll.dll
Error: Fatal import error in gwes.dll
Error: Unresolved external: FPCRT

The list goes on. Could someone give me advice for fixing this?


Dec 25, 2009 at 12:56 PM

Try "Clean Sysgen"

Pavel Belevsky

Dec 26, 2009 at 2:35 AM

Thanks for the reply Pavel, as I'm sure you can tell I am new to this stuff, but I'm learning so I'll have to try that out. I have done a Sysgen, and a clean then a rebuild, but i'll try the clean sysgen. I'll let you know. As always, I really appreciate your response and help. It seemed kinda dead in this group for a while, but it may just have hope yet.

Dec 26, 2009 at 3:39 AM
Edited Dec 26, 2009 at 10:52 AM

Well I appreciate the advice, but it appears that the same results occurred. I should note the following to better define the problem:

- the file: FPCRT.dll is successfully created and copied to the release directory

- sysgen.out shows the variable SYSGEN_OEM_FPCRT=1

- coredll.def shows FPCRT and import ordinals from the errors

- coredll.def has the following If Statements before FPCRT ordinals;


- ceconfig.h contains both:

            #define COREDLL_CORECRT 1

            #define COREDLL_FULL_CRT 1

All i can think of thus far is that this error may be caused by some setting required to make the subproject work correctly with coredll.dll. Any thoughts?




After thoroughly looking over the os design and release directory, it seems k.fpcrt.dll isn't built...I have no idea why this is, I am guessing this is just another problem that I am having.


Btw Pavel, it all of the sudden hit me who you were just now after going to reference the windows embedded ce 6.0 fundamentals book. Seeing as you literally wrote the book, I really appreciate you taking the time to help me, as I am new to developing os's for wince. If there is anything you could use a hand with/want me to document let me know. Since I am a student, I have some time, and I want to make sure I return the favor to those who help me.

Dec 26, 2009 at 11:53 AM

This article will help you:

Dec 26, 2009 at 12:56 PM
Edited Dec 26, 2009 at 12:57 PM

You are making it harder then it really is.

Just create another subdirectory in your OAL .. call it OALVFP add the whole FPCRT directory from ARM. mod the OAL dir.

Do NOT include the OEM floating point CRT (ARM) catalog item.





Dec 27, 2009 at 2:23 AM

Thanks for the response from both pavel and dvescovi.


I have ran into that site before, but I guess I just need to read it more thoroughly and to better learn the way things work in both wince and the platform builder to understand the error. I am still working away at the problem.



Although I am new to all of this, I believe you may be mistaken. According to pdf that comes with the vfp, this website (, and msdn (, SYSGEN_OEM_FPCRT=1 and this means that the catalog item SHOULD be included. Furthermore, according to all the documentation, failing to include the catalog item will result in the inclusion of the standard floating point CRT library from the OS design.

Have you tested your methods to ensure the VFP was enabled properly? If so, how did you test it? Keep in mind I am still working out the details of all this, but it appears to me the VFP CRT is replacing the standard CRT library. If you were to include the standard CRT library, I am not sure of the results, but it may take precedence over the VFP CRT, and therefore mislead you into thinking you have enabled VFP support when in actuality you have not. 

As for the comment you made about creating a subdirectory in the OAL, what is the benefit to doing that instead of following the direction in the release notes for the VFP and adding the supplied subproject to the solution?

I look forward to your response, as right now my only method of solving this problem is to take the time and better understand wince and the platform builder until I understand why the error is caused.

Dec 28, 2009 at 8:06 AM

Well, seeing as dvescovi has been doing this much longer than I have, and since I would at least like to have my platform successfully build, I have follow dvescovi's advice to not include the OEM floating point crt (arm) catalog item. I did not however change the directory I included to VFP from, and instead left it as a sub-project. As dvescovi predicted, the image did successfully build. That being said, does anyone have some good advice on testing to ensure the VFP is truly enabled? Thanks in advance for your time.

Dec 28, 2009 at 11:42 PM

Yea it really does work. I also had it as a subproject but then just included it all the time as default. Why would you NOT use it? I would guess the next release of Platform Builder the ARM BSP's will include it by default.

This is a simple test program. Without VFP when iteration gets up there it is really really slow.... several minutes between prints. With VFP its always less then a second.



// ARM_VFP_test.cpp : Defines the entry point for the console application.


#include "stdafx.h"

inline double doFloatingPoint(int iterationCount)


double result = 1.0000000000001;

for (int i=0; i < iterationCount; i++)


result *= sqrt(3.0);

result /= sqrt(2.99999);

// cos(x)^2 + sin(x)^2 = 1

result *= pow(sin(result), 2) + pow(cos(result), 2);


return result;


int _tmain(int argc, _TCHAR* argv[])


int iteration;

double results;


printf("VFP test ... \r\n");

for (iteration=0;iteration<=1000000;iteration+=5000)

// for (iteration=1000000;iteration>=0;iteration-=5000)


results = doFloatingPoint(iteration);



return 0;


Dec 29, 2009 at 1:33 AM

Thanks for the reply, that's good to here. I appreciate the test code, I'll give it a shot and let you know if everything works out.

Dec 29, 2009 at 2:48 AM

Everything appears to work fine. I ran the test, and the first 10-20 calculations took under a second, but the next ones start taking more like 1-2. I will run the test against an older build that didn't have VFP enabled and let you know the results. Thanks again dvescovi, and if there's anything I can do for you let me know.