On Tue, 1 Aug 2006, Jasper Wallace wrote:
> I built exim 4.62 with libspf2-1.2.5. That version of libspf2 uses pthreads,
> how or why i'm not sure. But the result of linking it with exim is that
> _res() which exim uses and which is a macro for __res_state on NetBSD 3.0
> ends up using the __res_state function in libpthreads which calls abort()
> cos it's not thread safe.
>
> It also prints an error message to stderr, which is helpful cos fd 2 is
> /dev/null when exim is running as a daemon :(
>
> The attached patch uses __res_get_state and __res_put_state instead, which
> works for me.
>
> I appreciate this the whole resolver api is a portability nightmare,
> but at least this will sitin the list archives if someone else goes looking
I have now got round to looking at this. It *shouldn't* be a portability
nightmare, as the details are supposedly all hidden away in macros, etc.
I've been able to look at two systems, Linux and FreeBSD. In both cases,
"man resolver" tells you to do exactly what Exim does, namely, use the
macro _res to handle options. On FreeBSD 5 there is this warning:
This implementation of the resolver is thread-safe, but it will not func-
tion properly if the programmer attempts to declare his or her own _res
structure in an attempt to replace the per-thread version referred to by
that macro.
Neither of these systems appears to have __res_get_state or
__res_put_state. NetBSD has apparently gone down a different path here.
I don't think there is anything I can do about this in the main Exim
source, so I'm afraid it will indeed just have to sit in the archives.
But thanks for posting.
Philip
--
Philip Hazel, University of Cambridge Computing Service.
