RE: libopendkim make check broken (trunk)

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Wed, 11 Nov 2009 11:56:07 -0800

> -----Original Message-----
> From: opendkim-dev-bounce_at_lists.opendkim.org [mailto:opendkim-dev-
> bounce_at_lists.opendkim.org] On Behalf Of Murray S. Kucherawy
> Sent: Wednesday, November 11, 2009 9:02 AM
> To: Daniel Black; opendkim-dev_at_lists.opendkim.org; Murray S. Kucherawy
> Subject: RE: libopendkim make check broken (trunk)
>
> > -----Original Message-----
> > From: opendkim-dev-bounce_at_lists.opendkim.org [mailto:opendkim-dev-
> > bounce_at_lists.opendkim.org] On Behalf Of Daniel Black
> > Sent: Wednesday, November 11, 2009 5:07 AM
> > To: opendkim-dev_at_lists.opendkim.org; Murray S. Kucherawy
> > Subject: libopendkim make check broken (trunk)
> >
> >
> > Me looks at Murray
> >
> > dkim_dstring not exported by library so can't access them. Can't add
> > dkim-
> > util.c to test88_SOURCES as it need dkim_error which is hidden.
> > [...]
>
> This is what I mean by some systems honour the symbol list and some
> don't. On FreeBSD, libtool doesn't appear to think gcc can be told
> which symbols to export, so I get them all and the tests pass.
>
> I think Solaris x86 did honour the limited list, so I'll sort it out
> over there.

Turns out the reduced symbol list really creates a monkey wrench in the library unit tests. I had to rewrite a couple of tests so that they don't use the dstring stuff, and tests 113 (direct dstring testing) and 118 (fake DNS testing) have been temporarily disabled until I figure out ways to make that code available for those tests to run.

I also took out all the "#ifdef"s from test programs that checked on SHA256 availability, replacing them with calls to dkim_libfeature().

But "make check" on the trunk should now be working again; it is at least passing on Solaris x86 and FreeBSD.
Received on Wed Nov 11 2009 - 19:56:16 PST