[geos-devel] [#317] Build configuration for CMake build system

Mateusz Loskot mateusz at loskot.net
Tue Jan 26 17:51:35 EST 2010


Sandro Santilli wrote:
> On Mon, Jan 25, 2010 at 10:17:34PM +0000, Mateusz Loskot wrote:
>> #include <math.h> #ifdef isfinite #error isfinite defined #else 
>> #error isfinite NOT defined #endif
> 
> I guess you just can't expect isfinite to necessarely be a macro. It 
> could be a real function too.

No. Talking about standard library, the C99
in "7.12.3.2 The isfinite macro" clearly specifies that
isfinte is defined as macro, not a function.
POSIX defines it exactly the same way, moreover, it specifies that it
shall be defined as in C standard.
gnulib does the same.

This is what I test and what I expect to work in consistent way.

> The autotool based version of the check actually attempts linking to 
> figure out:
> 
> dnl - Look for finite and/or isfinite macros/functions ... 
> [AC_TRY_LINK([#include <math.h>], ...

Right, so another paranoid behaviour of one GNU tool against
another GNU tool :-)
Sure, I can perform the same tests with CMake...

>> The simplest one would be to define something like this:
>> 
>> inline bool isfinite(double v) { return v >= 
>> -(std::numeric_limits<double>::max)() && v <= 
>> (std::numeric_limits<double>::max)(); }
>> 
>> but I'm concerned if it is robust enough on variety of platforms.
> 
> I suggest you do some more research on how cmake handles the case in 
> which a symbol may be a macro or function.

That's exactly what I've done of course.

The check_symbol_exists tests if a symbol is macro, if not,
it performs test if a symbol is function.
The test is a compilation test, no linking.

Here is complete log what the CMake check_symbol_exists
using GCC 4.3.3 with glibc 2.9 from Ubuntu 9.04:

/////////////////////////////////////////////////////////////////
Building C object CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.c.o
/usr/bin/gcc    -o CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.c.o
  -c
/home/mloskot/dev/geos/_svn/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c
/home/mloskot/dev/geos/_svn/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
In function ‘main’:
/home/mloskot/dev/geos/_svn/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:
error: ‘isfinite’ undeclared (first use in this function)
/home/mloskot/dev/geos/_svn/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:
error: (Each undeclared identifier is reported only once
/home/mloskot/dev/geos/_svn/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:8:
error: for each function it appears in.)
make[1]: *** [CMakeFiles/cmTryCompileExec.dir/CheckSymbolExists.c.o] Error 1
make[1]: Leaving directory
`/home/mloskot/dev/geos/_svn/build/CMakeFiles/CMakeTmp'
make: *** [cmTryCompileExec/fast] Error 2

File
/home/mloskot/dev/geos/_svn/build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <math.h>

void cmakeRequireSymbol(int dummy,...){(void)dummy;}
int main()
{
#ifndef isfinite
  cmakeRequireSymbol(0,&isfinite);
#endif
  return 0;
}
/////////////////////////////////////////////////////////////////


Let's repeat it manually, this is exactly the same test:

mloskot at vb-ubuntu904:~/tmp$ cat isfinite.c
#include <math.h>
void cmakeRequireSymbol(int dummy,...){(void)dummy;}
int main()
{
#ifndef isfinite
  cmakeRequireSymbol(0,&isfinite);
#endif
  return 0;
}
mloskot at vb-ubuntu904:~/tmp$ gcc -c isfinite.c
isfinite.c: In function ‘main’:
isfinite.c:6: error: ‘isfinite’ undeclared (first use in this function)
isfinite.c:6: error: (Each undeclared identifier is reported only once
isfinite.c:6: error: for each function it appears in.)


but if I ask for C99, what seems logical, then everything works well:


mloskot at vb-ubuntu904:~/tmp$ gcc -std=c99 -c isfinite.c
mloskot at vb-ubuntu904:~/tmp$


But why the heck I don't have to specify -std=c99 when using GCC 4.4.1
with glibc 2.10?

Either the former environment with GCC 4.3.3 is correct but GCC 4.4.1 is
buggy, or the other way around.
I reported it anyway:
https://bugs.launchpad.net/ubuntu/+source/gcc-4.3/+bug/512741

...in the meantime, I suppose the only way to deal with such problems
is to replicate the same tests as Autotools perform.

I'll take care of it.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org


More information about the geos-devel mailing list