[Patch] Fixing strcasestr detection for glibc-2.9

[Alexander Neundorf]

On Saturday 25 April 2009, David Faure wrote:
> This is a bit complex. When compiling string.h with g++, glibc-2.9
> defines two prototypes for strcasestr, a const one and a non-const one.
>
> This makes the check_function_exists fail because it tries to compile code
> that says "&strcasestr" -- which is ambiguous because of the overload.
>
> Some have said this is a cmake bug and it should be fixed in cmake so that
> it doesn't take the address of the function but does something more close
> to what autoconf did.
>
> Not knowing the reasons for the cmake implementation, I chose a simpler
> approach: since string.h defines __CORRECT_ISO_CPP_STRING_H_PROTO when it
> defines both versions of strcasestr, we can just check for that. Not as
> easy as it sounds though, because check_symbol_exists runs gcc and not g++
> (in which case string.h doesn't do all that magic, it's in #ifdef
> __cplusplus).
>
> So I had to fork check_symbol_exists into a check_cxx_symbol_exists which
> uses a .cxx extension instead of a .c extension.
>
> cmake guys: could check_symbol_exists take an option for the extension to
> use, maybe?

Yes, I think it looks good. I wouldn't even consider this ugly. A check for a 
C++-symbol is definitely missing in cmake, so the question is whether to have 
two variants, one with the "CXX" in the name, or only one where you can 
specify the language.
Since there are already other cmake modules with more than one version, one 
for C, one for C++, maybe one for Fortran, I think this is ok.

Alex