You really should document the fact that libol's class generation stuff requires scsh for its scripts to run, and syslog-ng uses a libol tool to rerun on the source files when they change. You might also add a functioning test to libol configure.in that will fail if scsh is not present instead of proceeding like it does now. Either and especially both of these things will save people time ;)

scsh is required only to hack on the sources, simply compiling it doesn't require scsh. I may put in some comments though. ... I added this to the README file: Hacking on syslog-ng ==================== Syslog-ng uses a nonblocking I/O, and OO library called libol. Libol uses a preprocessor to generate object definitions and information for the gc to collect garbage. Object definitions are structs and some small functions, and are placed in a file named something.c.x or something.h.x. These .x files are then included in the C source files. This preprocessor is written in Scheme, and requires scsh to run, but is not required to simply compile syslog-ng, since all needed .x files are included in the distribution. If you change a source file though, the .x file needs to be regenerated. By default all generated files are included in the distribution so scsh is only required if you want to change something in the source files. If the change you apply, doesn't change object definitions you don't need to rerun make_class, simply update the date of the .x file using touch:

It might also be a good idea to bundle the OL library with syslog-ng directly; do you have other programs which use libol ? The reason I suggest this is because I was really thrown for a loop with the EINPROGRESS stuff out of connect() that was fixed for .18; I built syslog-ng with .17 and ended up tracing down the problem with TCP relay manually only to discover afterwards that it was right in the ChangeLog for the new libol :) But I did not think libol was involved with respect to IO in syslog-ng, only with that OO C stuff it seems to be (I can't tell what it is exactly because there is not any documentation that I can find). Anyways it might be a good idea to just bundle a stable libol with syslog-ng and only update that version concurrent with syslog-ng version upgrades.

yes there are other projects that depend on libol (b-wall), though I always suggest distributor maintainers not to create a seperate package.

Now I am not sure about my memory problems, does libol also do memory allocation for syslog-ng?

libol provides the garbage collection framework. syslog-ng uses a mark&sweep garbage collector. libol was forked from lsh's I/O backend, you can read more about its internals in the file /doc/HACKING from the lsh distribution. (ftp://ftp.lysator.liu.se/pub/security/lsh) -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt