[syslog-ng] pdbtool patternize update and my syslog-ng 3.2 branch

[Balazs Scheidler]

On Sat, 2010-10-16 at 10:44 -0700, Matthew Hall wrote:
> On Sat, Oct 16, 2010 at 01:20:23PM +0200, Balazs Scheidler wrote:
> > On Fri, 2010-10-01 at 11:38 -0700, Matthew Hall wrote:
> > > Further investigation reveals that the syslog-ng daemon and 
> > > libsyslog-ng.so appear to be linking only against libc and its friends. 
> > > However pdbtool's linking against a truckload of external libraries as 
> > > shown before. It seems that the link logic is not consistent across 
> > > different binaries.
> > 
> > pdbtool immediately links against the libdbparser plugin, as it uses
> > some symbols in addition to the standard syslog-ng plugin interface.
> > Also pdbtool depends on libssl because it uses the random generator to
> > generate uuids.
> 
> I suspected something like this was the case.
> 
> > Also, syslog-ng starts early in the boot process and it was meant to be
> > loaded without libssl for instance. With pdbtool only used when the
> > system is up and running no such effort was made.
> 
> Yes, this makes sense, unless you are trying to run pdbtool on a distro 
> on which it cannot be compiled such as RHEL 4/5.
> 
> > But anyway the easiest way to distribute syslog-ng binaries between
> > different boxes is to do something similar to what we do, e.g. compile
> > everything into the same prefix and copy the whole structure.
> 
> Makes sense. If I can figure out how to get mixed linking to work for 
> other code besides the daemon itself. Otherwise it will not move over 
> due to version conflicts in the other libs like libevent, libssl, etc. 
> etc. etc.

you can always compile the libraries to a custom prefix so that it
doesn't break the core system.

> 
> > One thing caught my attention, you couldn't compile it on RHEL4/5? Why?
> > I'd love to investigate if there's a problem there.
> 
> On RHEL 4 and 5 it requires too new of a PCRE. 

Hmm.. I'm willing to change this, IIRC it is only the
PCRE_NEWLINE_ANYCRLF flag is missing from old PCRE, which can be
compiled conditionally.

Can you try the attached patch?

> If you install the PCRE, 
> you can break the system because other things could get angry that PCRE 
> was changed. But even when you try to compile PCRE that fails because 
> the autotools are too old and a ton of macros you need are missing.

autotools is not that important issue since I'm generating the files
when I release a tarball, so the generated files are there. of course if
you want to change the autotools input files, then that's a problem.

> 
> So I think there are some tricks to compiling it for RHEL that I am not 
> doing right, hence my questions about how Balabit managed to compile the 
> code because I couldn't figure it out at all.

And the patch:

$ git diff
diff --git a/configure.in b/configure.in
index 573ff42..775bbe5 100644
--- a/configure.in
+++ b/configure.in
@@ -24,7 +24,7 @@ GLIB_MIN_VERSION="2.10.1"
 EVTLOG_MIN_VERSION="0.2"
 OPENSSL_MIN_VERSION="0.9.8"
 LIBDBI_MIN_VERSION="0.8.0"
-PCRE_MIN_VERSION="7.3"
+PCRE_MIN_VERSION="6.1"
 
 dnl ***************************************************************************
 dnl Initial setup
diff --git a/lib/logmatcher.c b/lib/logmatcher.c
index f0a822c..44a84ed 100644
--- a/lib/logmatcher.c
+++ b/lib/logmatcher.c
@@ -520,8 +520,12 @@ log_matcher_pcre_re_compile(LogMatcher *s, const gchar *re)
  
   if (self->super.flags & LMF_ICASE)
     flags |= PCRE_CASELESS;
+
+#ifdef PCRE_NEWLINE_ANYCRLF
   if (self->super.flags & LMF_NEWLINE)
     flags |= PCRE_NEWLINE_ANYCRLF;
+#endif
+
   if (self->super.flags & LMF_UTF8)
     {
        gint support;



-- 
Bazsi