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