finding libmilter

From: Daniel Black <daniel.subs_at_internode.on.net>
Date: Mon, 23 Nov 2009 10:36:14 +1100

On Monday 23 November 2009 06:56:08 you wrote:
> 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?
nope.

> In fact, it looks like configure.ac was not changed, nor was
> libopendkim/Makefile.am or opendkim/Makefile.am.

apparently cvs can have files from different branches visable at the same
time. ouch. Blah and sorry again.

>
> 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=...".

agree. The problem was --with could not specify the path to include and lib at
the same time.

 dpkg -L libmilter-dev
...
/usr/include/libmilter/mfapi.h
/usr/include/libmilter/mfdef.h
/usr/lib/libmilter/libmilter.a
/usr/lib/libmilter/libsmutil.a
/usr/lib/libmilter/libsm.a
/usr/lib/libmilter/libmilter.so
/usr/lib/libmilter/libmilter.so.1.0.1
..
Received on Sun Nov 22 2009 - 23:37:24 PST