As all the calls to PKG_CHECK_MODULES are conditional, it can happen
that PKG_PROG_PKG_CONFIG is not called (i.e. if you not use
--enable-relp). So we enforce a check for pkg-config by adding it to the
global checks.
rsyslog also works with some 1.x.x versions, but I have not details any longer.
I developed with a v1 version for a while. To be on the save side, I request
2.0.0 (Michael Biebl was even more conservative with 2.4.2 - which he had
at hand - and so I am changing this now).
Remove AC_CHECK_HEADERS([mysql/mysql.h],...) as this was causing pain
for users where the mysql headers are not installed in the system include
directory. It was superfluous anyways, as we check for mysql_config and
set the include path to the correct directory.
Update ommysql.c to use #include <mysql.h>, as mysql_config will set the
include path to /path/to/include/mysql/ so <mysql/mysql.h> would not
work.
Remove errmsg.h include as it is not used.
To unclutter configure.ac and to make it easier re-usable, move the check
for atomic operations into a separate m4 macro file and call the macro
RS_ATOMIC_OPERATIONS (RS for RSyslog)
Use PKG_CHECK_MODULES instead of libgnutls-config to get the compilation
flags (vastly simpler). Set minimum version to 2.4.2, as that is the
oldest version I could test with.
As all the calls to PKG_CHECK_MODULES are conditional, it can happen
that PKG_PROG_PKG_CONFIG is not called (i.e. if you not use
--enable-relp). So we enforce a check for pkg-config by adding it to the
global checks.
pkg-config uses uppercase for its _CFLAGS and _LIBS variable names.
So we follow suit and convert all _cflags and _libs variables to
uppercase for more consistency.
... pointed previously to stunnel-alternative, which now that
we support native TLS is now no longer recommended.
Thanks to Michael Biebl for bringing this to my attention.
so that the "last message repeated n times" messages, if generated, may
have an alternate format that contains the message that is being repeated.
Note that this is on an action-by-action basis.
It looks like a race was introduced by not locking the message mutex
in msgDestruct(). In theory, I thought, the decrement should be atomic,
but the whole operation may be reordered. Also it has potential for task
switches. If so, that would lead to a too-early destruction and thus
a potential double free - exactly what we have seen from time to time.
So I think this fix addresses the issue.
I have also removed anything that looks like atomic operations are supported
in this version - they are not. This was very late added, found to be
non-portable and pulled from that release.
This was suggested by David Lang, to help identify the message that was
repeated. A problem is that I do not have the expanded template at
hand when the "last ... times" message is generated. Spending much time
on this functionality is also probably not a good thing, as the whole
functionality will be overhauled (and once this is done we will not at
all have the output template at hand). So the approach is to use a single
field - here msg - and inlcude it as a notation of what was repeated. This
is far from being perfect, but eventually good enough. I will now wait
for feedback before going any further.
