On Sunday 01 August 2010 23:26:10 Alessandro Vesely wrote:
> > PKG_CHECK_MODULES([OPENDKIM], [opendkim>= 1.2.2], [ ..... ] , [ ....])
>
> Thanks, I'll try that on the next occasion. IIRC, two issues I had in
> detecting the library are as follows:
>
> * zdkimfilter code is not multithreaded, so I don't want to have
> flags that require useless threading code, and
>
> * if libopendkim is built as a static library, I have to check
> further libraries separately.
There is pkg-config information that lists the full libraries to account for
the static linking case. I'm hoping the above macro handles it.
> > We'd like the libopendkim to be as usuable as possible so please let us
> > know if anything is packaged wrong or there are features/changes you'd
> > like.
>
> The multithreaded flag was (is?) probably unnecessary.
quite right - it still goes the mt path without arlib/unbound. Looking at fix
now..
> > Some quick suggestions/questions about your own product while i've been
> > looking:
> >
> > http://www.tana.it/sw/zdkimfilter/#install
> > Is the static recommendation really only related to opendkim-1*?
>
> In part. I haven't yet coded a runtime check that library and include
> versions match :-/
the ABI versioning on the library should handle that without your
intervention.
> OTOH, for most of the time zdkimfilter is the only
> linked executable, so the benefits of sharing it seem very small. See
> e.g.
> http://www.mail-archive.com/linux-kernel_at_vger.kernel.org/msg127835.html
the main benefit of shared libraries is security management on distos. A
security vulnerabilty in libopendkim gets harder to manage when there are
static compiles.
> > I recommend you do some form of check to see if opendkim reputation is
> > built in as part of your configure.ac.
>
> Noted.
AC_SEARCH_LIBS([dkim_get_reputation], [opendkim])
> I thought I could go away with the stub function.
I didn't see the stub funtion. My lack of looking.
> Thanks again for your interest in zdkimfilter.
np.
Received on Mon Aug 02 2010 - 02:31:44 PST