[syslog-ng] What is the last syslog-ng version that compiles under glibc-2.3.5 ?

[Balazs Scheidler]

On Sun, 2009-11-29 at 18:31 -0900, Mr. James W. Laferriere wrote:
> 	Hello Balazs ,
> 
> On Sun, 29 Nov 2009, Balazs Scheidler wrote:
> > On Sat, 2009-11-28 at 19:03 -0900, Mr. James W. Laferriere wrote:
> >> 	Hello All (& Jakub if he's interested) ,
> >>
> >>
> >> On Sat, 28 Nov 2009, Mr. James W. Laferriere wrote:
> >>>
> >>> On Sat, 28 Nov 2009, Jakub Jankowski wrote:
> >>>> On Saturday 28 of November 2009, Mr. James W. Laferriere wrote:
> >>>>>  	That seemed to get me past that 'configure' difficulty ,  But of
> >>>>>  course there is now another during 'make' :-( .
> >>>>>  	What include file am I missing now ?  This is surely symptomatic of a
> >>>>> missing include file or include file version level .  I've searched the
> >>>>>  whole of my logging system & not found any .h file with this symbol
> >>>>>  defined on it . This is getting disheartening .  Eventlog compiled w/o
> >>>>>  any problems at all .
> >>>> [...]
> >>>>> logmatcher.c: In function `log_matcher_pcre_re_compile':
> >>>>> logmatcher.c:534: error: `PCRE_NEWLINE_ANYCRLF' undeclared (first use
> >>>>>  in this function)
> >>>>
> >>>> Your pcre is probably too old. Either compile with --disable-pcre, or
> >>>> upgrade pcre.
> >>>> HTH
> >>> 	Yes  it did help .  But again another symbol is missing .  This one
> >>> seems to be in the tls libraries .
> >>>
> >>> 	I'd like to suggest that the maintainer of the configure.in start
> >>> checking for these symbols or AT LEAST the appropriate versions of the libraries
> >>> these symbols reside in .  The checking is obviosly not being done correctly or
> >>> completely .  As both of these symbols have been caught during compile time not
> >>> during the checking that configure does .
> >>>
> >>> 	Also Please remember not every system out there is able to be deeply
> >>> upgraded at many of its library levels .
> >>>
> >>> 	I remember having to dig out missing symbols back when I managed a
> >>> Ultrix system (on a uVax) trying to get pppd and tools to compile .  And just
> >>> about any other tool I wanted on that system .  But heck that was back in 1990
> >>> (and a little later) .  Then a little bit after that as Linux began being the
> >>> one OS I tended to lean toward .  But most packages have progressed very nicely
> >>> since then & I have not had to even think about these types of difficulties in
> >>> some many years .
> >>>
> >>> 	But I do have to admit this system needs a to the roots upgrade .  Which
> >>> I am working toward ,  But even that's getting a tad slowed down .
> >>> 	Sorry about the rant .
> >>> 	Please take that suggestion to heart tho .
> >>>
> >>> 		Twyl ,  JimL
> >>>
> >>> if gcc -DHAVE_CONFIG_H -I. -I. -I..   -I/usr/include/glib-2.0
> >>> -I/usr/lib/glib-2.0/include   -I/usr/local/include/eventlog       -D_GNU_SOURCE
> >>> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -g -O2 -Wall -MT main.o -MD -MP -MF
> >>> ".deps/main.Tpo" -c -o main.o main.c; \
> >>> then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit
> >>> 1; fi
> >>> gcc  -g -O2 -Wall   -o syslog-ng  main.o libsyslog-ng.a   -lrt -lnsl -lfl
> >>> -lglib-2.0   -L/usr/local/lib -levtlog   -lssl -lcrypto  -lz
> >>> libsyslog-ng.a(tlscontext.o)(.text+0x6ea): In function
> >>> `tls_context_setup_session':
> >>> /home/archive/syslog-ng-3.0.4/src/tlscontext.c:278: undefined reference to
> >>> `X509_VERIFY_PARAM_set_flags'
> >>> collect2: ld returned 1 exit status
> >>> make[2]: *** [syslog-ng] Error 1
> >>> make[2]: Leaving directory `/home/archive/syslog-ng-3.0.4/src'
> >>> make[1]: *** [all-recursive] Error 1
> >>> make[1]: Leaving directory `/home/archive/syslog-ng-3.0.4'
> >>> make: *** [all] Error 2
> >>
> >>  	Now I am confused ,  There is a .h file with the necessary symbol
> >> definition on my system & configure did not use that include file obviously .
> >>  	Unless there is something in the ld commands that forces the use of
> >> a *.so|*.a file instead (something like '-Bdynamic, -dy, -call_shared' ... ?
> >
> >>
> >>  	I had just finished updating openssl (several days ago) & running
> >> ldconfig as well afterward in order to re-compile my ssh .
> >>
> >> # dir /usr/include/openssl/x509_vfy.h
> >> 24 -rw-r--r--  1 root root 20782 2009-11-22 12:05 /usr/include/openssl/x509_vfy.h
> >>
> >>  	Lets see what the symbols definition looks like .
> >>
> >> # grep -C1 X509_VERIFY_PARAM_set_flags /usr/include/openssl/x509_vfy.h
> >>
> >>   int X509_VERIFY_PARAM_set1_name(X509_VERIFY_PARAM *param, const char *name);
> >> :int X509_VERIFY_PARAM_set_flags(X509_VERIFY_PARAM *param, unsigned long flags);
> >>   int X509_VERIFY_PARAM_clear_flags(X509_VERIFY_PARAM *param,
> >>
> >>  	Just in case there are more than one installed instance of openssl ,  It
> >> could have been hiding in /usr/local or some such ,  like I said this is an old box .
> >>
> >> # find / -xdev -name x509_vfy.h -ls
> >>
> >> 3565418   24 -rw-r--r--   1 root     root        20782 Nov 22 12:05 /usr/include/openssl/x509_vfy.h
> >
> > What you get is a linker error, whereas the header file is used only by
> > the compiler. So you seem to have an .so file that doesn't match your
> > headers.
> >
> >
> > X095_VERIFY_PARAM_set_flags() is defined by openssl 0.9.8 and syslog-ng
> > is explicitly depending on 0.9.8. You probably also have 0.9.7 as well
> > and for some reason the linker finds that.
>  	That hit the nail on the head (& mine) .
>  	(*) ie: /usr/lib/openssl.so.0 -> openssl.so.0.9.7
>  	re linked to openssl.so.0.9.8
>  	And all compiled fine .
>  	Updated pcre to minimum needed just prior .
> 
> 
> > Regarding the rant, you're right that compiling a package from source
> > with a lot of external dependencies is not and has never been easy.
> > Especially if your build host has hacks and mismatching
> > headers/libraries.
>  	Still checking for the minimum required libraries in configure.in is 
> quite doable & someone missed the possibility of the above (*) and it did not 
> get caught .  Not to mention the operator (me) didn't either :^( .

In the openssl case, syslog-ng does check the version number:

PKG_CHECK_MODULES(OPENSSL, openssl >= $OPENSSL_MIN_VERSION,, OPENSSL_LIBS="")

OPENSSL_MIN_VERSION contains 0.9.8, however syslog-ng relies on the
standard pkg-config mechanism, and doesn't attempt to link against the
lib found this way.

Regarding pcre, you're right, pcre version number checking is not there.

> 
> > However you could always try to install syslog-ng binaries, which you
> > can find on BalaBit's homepage at:
> >
> > https://www.balabit.com/network-security/syslog-ng/opensource-logging-system/#
> >
> > Click on the "Downloads" tab, then "Sources & binaries"
> >
> > We don't support these binaries on Slackware, however even if the
> > install.sh script fails, you could always extract the binaries using
> >
> > ./syslog-ng<version>.run --tar xvfz
> >
> > then copy the binaries to /opt/syslog-ng and doing the necessary steps
> > to disable syslogd & start syslog-ng in the boot process.
>  	Beleive me I am aware that balabit does not support slackware packages .
>  	And the only way i could use those packaged binaries is if they were 
> statically linked .

no, the package above includes _all_ necessary .so files to run
syslog-ng, except for glibc.

the reason we're linking dynamically against those .so files is that the
GPL requires us to supply dynamically linked binaries against LGPL
libraries, in order to make it possible to replace the .so file with a
changed version.

If you at least run on a glibc version that matches Debian sarge (where
we compile our packages), you should be fine with the above binaries.
sarge uses "2.3.6", so do we depend on that version.

>  	But I've gotten things straightened enough that syslog-ng-3.0.4 now 
> compiles succssfully ,  not saying that the binary I've created is usable but 
> ...
>  	I'll give this a try and go from there .



-- 
Bazsi