Unable to link Embarcadero XE4 project when using floorf() function

Question

I need to use the floorf() function defined in Math.h and while I can compile the module where this is used successfully in my XE4 project, I receive this error when linking:

 [ilink32 Error] Error: Unresolved external '_floorf' referenced from <myfilename>.OBJ [ilink32 Error] Error: Unable to perform link 

This makes no sense - the compiler obviously knows where the function is declared as it opens Math.h when I control-click on the floorf() function. and I've included #include in the .cpp file. What do I need to get this working? I really need to use this standard math function.

Answer 1

Linking with math library is not enabled by default in some compilers.

gcc: why the -lm flag is needed to link the math library?

Answer 2

I use BDS2006 so this may not help but:

1. try to use floor() instead of floorf()
   • if you have ambiguility problems use float(floor(float(x)));
2. try to include instead of or the other way around to see if it helps
3. do you use any namespace? (try to use ::floor() )
4. didn't you forget some ; , { , } , }; ? especially in struct / class / namespace
5. do you use #define s ?
   • borland/embarcadero has sometimes problems with code inside defines
   • very rarely it compile it wrongly so the code does not work as it is written
   • did see this few times usually swapping/inserting some lines (even empty) helps
6. where do you use the floorf function (cpp file or unit or form)?
   • if you add unit file to the project (with your own stuff not Window/Form code)
   • then it is presumed to be VCL/machine generated stuff like Form not standard C/C++ file
   • and it is compiled/linked differently
   • if this is the case remove the file from project
   • and add include of it to one of the Form cpp/h files where it is needed
   • I saw this behavior in BCB5,BCB6,BDS2006
7. do you use some #define s that collide with math internal compilation tokens?
   • some defines could be used internally to enable//disable parts of code inside math
   • so if you define the same prior to math include you can mess with it
   • do not use tokens like _math , _floor ...
8. how do you name your own functions
   • if they collide with VCL names then weird stuff starts to happen
   • the typical is own Draw() functions with collision with internal TForm::Draw
   • no bug is reported but sometimes the code does not work (even if call operands are not the same)
   • last saw this on BCB6
   • just rename those to draw() and you will be fine unless you are bound to some naming scheme

My bet is the point 6 saw it many many times back in my teaching times