Add linux friendly implementations of strlcpy and strlcat

[TomasKorbar]

Add implementations of strlcpy and strlcat to opendkim

Implementations were taken from libbsd to maintain compatibility.

List of changes and their justification:

configure

• rebuild configure script because of changes in configure.ac

configure.ac

• added subdir-objects to automake options because linux_string folder is used in multiple makefiles and is in subdirectory (some warnings are displayed without it)
• Removed check for getgroups function because
  1. it is no longer used in any source file
  2. in my opinion bug in autoconf was forcing configure script to link libbsd to get getgroups function even if it is included in glibc
• added template, argument and automake conditional for --use-bundled-strl argument. It was neccessary to change structure of some conditionals because of this change.

libopendkim/Makefile.am

• added automake conditionals for USE_BUNDLED_STRL

opendkim/Makefile.am

• added automake conditionals for USE_BUNDLED_STRL

*.c files

• added build time conditionals for USE_BUNDLED_STRL macro

[egberts]

Wow... Thanks!

Accidentially filed same bug to SourceForge and Debian on this, but that configure has that inability to detect the file/file.h for strlcat/strlcpy C declarators and is still an issue with 2.11.0-alpha-8 (Debian variant).

Perhaps, updating the opendkim to point to a NEWER "bugzilla" location/URL?

References:

• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948504
• https://sourceforge.net/p/opendkim/bugs/250/

[glts]

@egberts This pull request does not fix a bug, it is a proposal to get rid of a dependency. It is a preference not something strictly necessary.

[egberts]

I fixed my issue by installing libbsd-dev, Debian package.

[TomasKorbar]

@egberts This pull request does not fix a bug, it is a proposal to get rid of a dependency. It is a preference not something strictly necessary.

Yes

I fixed my issue by installing libbsd-dev, Debian package.

Of course. This is just a way how to build OpenDKIM without that dependency:)

[martinbogo]

The dependency is there so that we don't have to maintain a separate implementation of these functions. Although we don't specifically target any distributions... the Trusted Domain Project does strive to maintain compatibility, maintainability, and security as much as possible.

The dependency on libbsd-dev is there as designed and will remain for now. If we need to change that in the future, this PR may help, but it will not be merged in.