On Wed, Nov 21, 2012 at 06:59:35AM -0800, Murray S. Kucherawy wrote:
> On Wed, 21 Nov 2012, Eray Aslan wrote:
> > warnings during build with commit 9d3b6fbf. These warnings are never
> > good and I would like to avoid them if possible. Checking for native
> > implementation first and if not found checking for strl.h and if that is
> > not found as well, assuming an external strl library is not available
> > and building our own seems to be a better solution.
>
> 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.
> > 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.
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.
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.
> > - 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.
> > - 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.
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.
> 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.
> 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.
These problems are only for Linux obviously. BSDs are good.
--
Eray
Received on Wed Nov 21 2012 - 20:29:57 PST