Re: code review - br-msk-reduce-symbols

From: Daniel Black <daniel.subs_at_internode.on.net>
Date: Fri, 6 Nov 2009 21:19:58 +1100

On Friday 06 November 2009 20:02:33 Murray S. Kucherawy wrote:
> On Fri, 6 Nov 2009, Daniel Black wrote:
> > bad news is the string functions dkim_str* don't link in opendkim (they
> > aren't in dkim.h):
>
> The function doesn't work on all platforms; on FreeBSD for example, the
> entire set of functions still gets exported.
how odd. I have a hunch a local m4 directory patch that I'll make a branch
soon will fix for the case where it is aclocal(ed) on a machine with a more
modern libtool.m4

should also fix the cranky centos problem you had too without a libtool
update.

> I managed to get it to
> provide a limited set of symbols on Solaris, but it didn't catch this case
> because strlcpy() and strlcat() are available there.
>
> > to add them or not? Not sure here.
>
> The simplest thing to do is probably to modify libopendkim/symbols.sh to
> check dkim-strl.h for symbols as well.

ok so we need to install those header files too. See latest commit on your
branch.

a little more future ruggedness could be achieved by using $(HEADERS) as a
symbol.map dependency but its good for now.

> > As per the patch attached, I think the generation could be handled with
> > a little less indirection however that's just personal preference.
>
> Works for me.

good.
 
> > libvbr seems to have more in vbr.h than nm -g --defined-only
> > ./libvbr/.libs/libvbr.so
> > don't know why - didn't look that hard.
>
> The three things in vbr.h missing from the "nm" output were guarded by
> "#ifdef USE_ARLIB".

ah thanks.

> The export list hasn't been normalized there yet.
>
because its not exporting stuff between files it doesn't need to be normalised
in the same way.

good to merge from me.
Received on Fri Nov 06 2009 - 10:20:31 PST