Re: OpenDKIM v2.7.2 released

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Wed, 21 Nov 2012 13:37:58 -0800 (PST)

On Wed, 21 Nov 2012, Eray Aslan wrote:
>> Under those conditions, there's quite possibly a libstrl already installed
>> without a strl.h, so trying to install our own libstrl would cause a
>> filename collision and an install failure.
>
> I know of only one implementation of libstrl other than opendkim in
> Linux and it provides a strl.h file. Besides, providing a library for
> external consumption without a corresponding header file is odd. I do
> not think it is something we should worry about happening.

It's not odd if you don't intend to have others use the installed library.
But either way, since 2.7.0, we have installed a strl.h in a subdirectory
called "strl" inside whatever the configured include directory is. On my
test system it's in /usr/local/include/strl/strl.h.

>>> In other words, our options seem to be, in no particular order
>>> - rename internal libstrl library
>>
>> I'm not too keen on peppering people's installations with a variety of
>> strlcat/strlcpy implementations. We probably shouldn't do this.
>
> Fair enough. It is not unheard of though - see libevent, libev, etc.
> Also, I was thinking that most projects would migrate to the "better"
> implementation and eventually there would be one de facto standard. But
> yes, this is not guaranteed to happen and renaming is not an ideal
> solution.

I think if there's enough demand to do so, we could package our libstrl
separately. But I also think libevent, libev, etc. are different in that,
unlike the conflicting libstrl implementations, they don't try to provide
the very same API.

> But not renaming is complicating our job. When we see a libstrl.so
> during build, we cannot know whether that file belongs to some external
> library - we should link against it - or belongs to some previous
> version of opendkim - do not link against it.

Does it matter? We need those two functions, regardless of which
lirbary they're in.

Why would we not link against an older version of our own library? In
fact, as of now at least, they're codewise identical.

We could add checks to configure to compile a small program that exercises
any discovered functions to make sure they produce expected results if we
really want it to be bulletproof.

> Alternatively, we can try and differentiate between these two options
> - link or not link - with some added complexity in configure script.
>
> Still another alternative, do not check and always build and use
> internal implementation on Linux.

That's basically what I suggested below: If strl.h and strlcat/strlcpy are
not all available, build our own static one, link against that, and never
install it. Then it doesn't matter what the rest of the system has or
doesn't have, and we don't leave any files on the system that have
anything to do with this issue.

>>> - provide strl.h along with the libstrl library
>>
>> By that you mean install strl.h if there isn't one, even if you're not
>> installing the library?
>
> No. I meant either install both libstrl.so and strl.h or do not install
> them at all.

I'm not understanding how you have one and not the other. Does "find /usr
-type f -name strl.h" return nothing? (Assuming you use /usr/include and
/usr/local/include and no other include locations.)

It's possible the error is simply that we aren't adding a check for strl.h
in the aforementioned subdirectory. If you do a "find" to locate it and
then add CPPFLAGS=-I<that-location> to your ./configure command, does the
warning go away?

>>> - include strl in LIBS only if strl.h is found
>>
>> Wouldn't that cause runtime failures or build failures, since that would
>> mean those functions go unresolved?
>
> Nope. Why unresolved? If there is strl.h and libstrl.so both, we use
> them. If not, we use the internal implementation.

If we include -lstrl in LIBS only if strl.h is found, that also means
"don't link against libstrl if strl.h is absent". On Linux, that would
leave strlcat and strlcpy unresolved.

Unless you mean don't try to link against the system's libstrl if strl.h
is not installed, and use our own. That's possible, of course, but it
shouldn't be necessary.

> On a system which has <=opendkim-2.7.1, we are linking against
> libstrl.so during build of 2.7.2 becasue of
> AC_SEARCH_LIBS([strlcat]...) in our configure script. That macro
> adds -lstrl to LIBS variable when it sees the libstrl.so. Later, when
> we try to use the symbols defined in libstrl, we get the
> implicit-declaration warnings because, well duh, they are not declared
> before use - there is no header file.

Since you should have a strl.h in a subdirectory someplace, it's possible
all that's missing is for us to add a -I to CPPFLAGS to reference the
subdirectory, once we confirm it's there.

>> A fourth option would be to force our libstrl to be static, always link
>> against that, and never install it.
>
> Yes, that is another option. And a good one. But please note that this
> is not very different from the "peppering" option in principle. But
> still, sidesteps the problem. Good choice.

I disagree. It leaves no nth installation of the strlcat/strlcpy
functions on the system; it's completely self-contained.

>> A fifth option would be to provide documentation that we got 2.7.1 wrong
>> by not installing strl.h, and have people manually remove our libstrl from
>> those installations before doing "make install" for 2.7.2 or later, if
>> they want those warnings to go away.
>
> That would be a bad user experience for people installing from source
> and for source based distro users.
>
> Even then, linking against libstrl.so from a previous version of
> opendkim is not good. Current code would run into this problem when
> opendkim-2.7.3 comes out for example.

Why? Since there have been no changes to the library itself, the output
library is identical. A problem only occurs if the exported APIs are
different, or they otherwise have different and incompatible behaviours.

-MSK
Received on Wed Nov 21 2012 - 21:38:17 PST