On Tue, Nov 20, 2012 at 01:44:22PM -0800, Murray S. Kucherawy wrote:
> It would be nice to force a reinstall of libstrl if we installed our own
> before without strl.h, but I think that's probably complicated to do
> automatically.
Yes, it is (needlessly?) complicated as long as we keep the same name as
the external libstrl library.
Opendkim's libstrl library is a good implementation and other projects
might find it useful as well which you can promote by installing a
strl.h header file. That would solve our problem as well. We would
always build libstrl if on Linux - if strlcat and strlcpy is not
provided natively. Downside would be opendkim and the external libstrl
library would not be compatible. They cannot be installed at the same
time.
> The above is now committed to git, tested on FreeBSD (which has the two
> functions native), and on a Linux box with and without a libstrl
> installed. Let me know if you'd like a revised tarball to try.
When a previous opendkim version is already installed on the system, I
am getting a bunch of
util.c: In function ‘dkimf_checkip’:
util.c:495:4: warning: implicit declaration of function ‘strlcat’
[-Wimplicit-function-declaration]
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.
In other words, our options seem to be, in no particular order
- rename internal libstrl library
- provide strl.h along with the libstrl library
- include strl in LIBS only if strl.h is found
--
Eray
Received on Wed Nov 21 2012 - 09:28:33 PST