Re: debian testing

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Sun, 22 Nov 2009 11:56:08 -0800 (PST)

On Sun, 22 Nov 2009, Daniel Black wrote:
> As you can see i've merged the autoimprovments into trunk and fix a few
> things.
>
> Outstanding defects:
>
> 1.
>
> The last commit I did regarding AC_SEARCH_LIBS(milter) introduced a little
> configure uglyness:
> "
> checking for milter library and includes... checking for library containing
> smfi_register... -lmilter
> /usr
> "
>
> (but it was needed to make it compile on a lenny machine)

I don't see this check in the trunk yet so I assume you mean it's only on
the branch (which is closed?). Was this intentional?

In fact, it looks like configure.ac was not changed, nor was
libopendkim/Makefile.am or opendkim/Makefile.am. All of the source code
changes did merge though. That means they're all looking for
build-config.h now, but configure.ac isn't setting feature macros in there
and all the FFR settings are still coming via automake macros. Looks like
only a partial merge was done.

Anyway, back to your note: opendkim's compilation requires definitions
that are in libmilter/mfapi.h as well as the library. If you want to use
AC_SEARCH_LIBS to find smfi_register(), you should probably also plan to
use AC_CHECK_HEADERS to find libmilter/mfapi.h. Then we can get rid of
the manual checks below. Just be sure that failure of either of those
tests results in a fatal error from ./configure. I opted to tie it to
"--with" because I think that method is more palatable to junior sysadmins
than having to do "CPPFLAGS=... LDFLAGS=...".

Checking for smfi_setsymlist() is a good idea, as it wasn't present in
older versions of libmilter. An alternate way might be to look for the
macro SMFIF_SETSYMLIST which one can presume is defined if the installed
libmilter contains that function. In either case, you could put an
appropriate #ifdef around the code block starting at around line 5259 of
opendkim.c once you have something that can be checked in build-config.h.

> Currently we're checking strongly against libtre-0.8.0 by looking for
> tre/tre.h (which is only in the 0.8.0 version. Can we use 0.7.5 as this is the
> stable version on lenny?
> yes - change check in configure.ac and source code to use tre/regex.h
> no - change the error to explictly mention we require the 0.8.0 version

Sure, we could use either one if they're API-compatible. We'll have to
teach libopendkim to include whichever one is actually present. Sounds
like a job for AC_CHECK_HEADERS and build-config.h once the merge is
fixed.

> We almost could make this work on the libmilter-8.13 found in debian
> etch and potentially other old stable machines. The only compile time
> symbol not found was mfi_setsymlist to do with macro checking. A
> configure check for this and subsequent disabling of macro features
> could increase portability.

Yep, I'm in favour of that. Suggestions above.
Received on Sun Nov 22 2009 - 19:56:42 PST