A long long time ago, upstream and BalaBit's version of ivykis started to diverge, which - at the time - was necessary, but the intent always was to eventually get things upstream and merged, to allow syslog-ng to use upstream ivykis, as-is. With the help of Lennert Buytenhek (ivykis upstream) and Balazs Scheidler, I present you the first work in progress patch set against syslog-ng that enables it to work with an unmodified ivykis! The patch set is not 100% complete yet however, I'm only submitting it for review and possible testing. I will probably port it to 3.3 too (it applies almost cleanly, there's only one trivial conflict in lib/Makefile.am) and build the Debian packages using upstream ivykis to get wider testing. What is missing, is the old lib/ivykis/configure.gnu script, which we had there to force a static build of ivykis. This will be replaced by a modification to autogen.sh, that will automatically create the configure.gnu scripts in the various submodules, so we can point the submodule links to upstream repos instead of our own forks. This is not included in this set yet, and one will need to copy that file over from the BalaBit fork, or things won't work too well. Another thing is that the first patch stops libsyslog-ng-crypto from being directly linked to ivykis. This is not an issue when ivykis is statically compiled into libsyslog-ng, since all those symbols will be exported to other modules, including libsyslog-ng-crypto. However, it might become a problem when using a dynamically linked ivykis. I haven't tested that case yet. The reason I remove the link is that if ivykis is statically compiled in to both shared objects, the constructors will run twice, as dlopen()ing anything linked against libsyslog-ng-crypto will trigger them again. This leads to an abort() inside ivykis. This can be done on the ivykis side too: separate the constructors from the init functions, and make the constructors no-op if they ran already: this allows the init functions to continue aborting if called more than once, but allows the constructors to run twice. I have to discuss this with upstream, and see if we need this at all, or if my workaround of removing the linkage from libsyslog-ng-crypto is enough and without side effects. These were the easy issues, which I could solve right now if I had some coffee left. But alas, there is another issue! With the first two patches applied, we'd have a syslog-ng that compiles fine against upstream ivykis, and even works. Except it doesn't: whenever we try to set an io handler for an fd, we'd end up in an abort, because for some reason, we already had a handler set. I do not understand it quite yet why this happens - the old BalaBit fork of ivykis was similarly picky and abort-happy and they did not trigger. As a workaround, I created the third patch, because I wanted to have something that shows signs of working. The third patch is *WRONG*, but it's an acceptable workaround until I have time to debug the problem further. What it does, is that it *always* clears the io handlers before registering new ones. This results in marginally more work being done each time we need to set a handler, but not by much, and as far as I saw, it has no side effects. But since the part of ivykis that aborts before the third patch, did not change between BalaBit's fork and upstream, I'm certain that the second patch introduces a bug that wasn't there before. Nevertheless! The good news still is, that we're *very* close to being able to build with upstream ivykis! A few issues to fix, and then comes the next part: going over all the changes that were made to the BalaBit fork of ivykis, and send everything upstream that has not been sent yet. That will be another funny adventure, but at least, by that time, I will understand what the hell I am doing =) -- |8]