On Monday 04 May 2009 11:51:49 am David Faure wrote: > 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? > > > > Meanwhile, ok with this patch for kdelibs? > > No feedback. Should I just commit this ugly fork and forget about it? ;-) >
I'd rather we replace the very few uses of strcasestr with QString or QByteArray usage. There are only 2 places it is used: in kdepimlibs/kmime and kdeadmin/lilo-config (according to lxr.kde.org) I volunteer to deal with kdepimlibs/kmime If using Qt isn't good enough, I have no objections to the ugly fork. _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
