Bug#388243: cyrus-imapd-2.2/cyrus21-imapd: FTBFS on GNU/kFreeBSD

[Petr Salinger]

>>> --- cyrus-imapd-2.2-2.2.13/configure.in
>>> +++ cyrus-imapd-2.2-2.2.13/configure.in
>>> @@ -300,7 +284,7 @@
>>>  	AC_CACHE_VAL(cyrus_cv_sys_psstrings, AC_TRY_CPP([
>>>  #include <machine/vmparam.h>
>>>  #include <sys/exec.h>
>>> -#ifndef PS_STRINGS
>>> +#if !defined(PS_STRINGS) || defined (__GLIBC__)
>>>  #include </nonexistent>
>>>  #endif],cyrus_cv_sys_psstrings=yes,cyrus_cv_sys_psstrings=no))
>>>  	if test $cyrus_cv_sys_psstrings = yes; then
>> 
>> This seems odd: Why is PS_STRINGS defined by sys/exec.h or
>> machine/vmparam.h if it isn't actually supported?
>
> In general, PS_STRINGS resolves to an absolute address, but
> value of PS_STRINGS in compiled binary might not be same
> as value used to compile current kernel :-(
> Better would be using C equivalent of "sysctl kern.ps_strings".
>
> We have in <sys/exec.h>
> #define PS_STRINGS      (USRSTACK - sizeof(struct ps_strings))
> but USRSTACK is defined only for kernel build.
>
>> I would include the fix, but I'm really not sure wether it is the right
>> fix to the problem.
>
> Would be "try to compile" following snippet acceptable ?
>
> ****************************
> #include <machine/vmparam.h>
> #include <sys/exec.h>
>
> void *p = PS_STRINGS;
>
> int main() { return 0;}
> ***************************

Corresponding snippet in configure.in would be

if test "$spt_type" = ""; then
         AC_MSG_CHECKING(for PS_STRINGS)
         AC_CACHE_VAL(cyrus_cv_sys_psstrings, AC_COMPILE_IFELSE([
#include <machine/vmparam.h>
#include <sys/exec.h>
void *p = PS_STRINGS;
],cyrus_cv_sys_psstrings=yes,cyrus_cv_sys_psstrings=no))
         if test $cyrus_cv_sys_psstrings = yes; then
                 spt_type=SPT_PSSTRINGS
         fi
         AC_MSG_RESULT($cyrus_cv_sys_psstrings)
fi


Petr