Broken autodetection of strlcat and strlcpy

[gagern]

The boinc configure script tries to guess automatically whether or not functions called "strlcat" and "strlcpy" are available. It does so by compiling a short snipped of code that includes both a dummy prototype and a function call, and linking it against the current set of libraries. This can break on some setups.

More precisely, it breaks for me with the following setup:

1. Gentoo Linux, so I'm compiling from source
2. Heimdal kerberos, which includes strlcat/strlcpy in its libroken.so
3. Curl compiled with kerberos support, so libcurl will depend on libroken
4. GCC 4.3.x, which will signal errors for functions without prototype

Boinc uses curl, so libcurl is in the current set of libraries when configure tries to compile its short snippet of code. By transitive dependency, so is libroken. As the snipped contains a prototype, and the symbol is present in a library, the configure test succeeds. Later on, when boinc code tries to call these functions, it includes no header providing prototypes to these functions, resulting in a compiler error like this:

boinc_api.cpp: In function ‘bool update_app_progress(double, double)’:
boinc_api.cpp:274: error: ‘strlcat’ was not declared in this scope

While heimdal might provide prototypes to these functions somewhere in its headers, trying to let configure find them seems the wrong approach, especially since heimdal is only an indirect dependency of boinc, and the functions are not part of the official kerberos API afaik.

Instead, I think configure should check for these functions not only by symbol name in a library, but also by header using a small test fragment which doesn't provide the prototype itself. If no usable implementation is found in this fashion, the one provided by boinc should be used. Probably the symbols should be renamed (e.g. to boinc_strlcat and boinc_strlcpy), so that there won't be clashes when different libraries provide the same symbols and an application loads them both.

See also ​Gentoo bug #248769.