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

[Mr. James W. Laferriere]

 	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 :^( .

> 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 .
 	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 .

 		With thanks to Jakub & Balazs .  Twyl ,  JimL
-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network&System Engineer | 3237     Holden Road |  Give me Linux  |
| babydr at baby-dragons.com | Fairbanks, AK. 99709 |   only  on  AXP |
+------------------------------------------------------------------+