On Mon, May 07, 2012 at 11:42:30PM +0200, Gergely Nagy wrote:
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!
(Whoops, I didn't see this email until now.) Yay! Thanks for doing this work.
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.
If the constructors run twice but bss variables are still shared, then yeah, we should do something like what you said.
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.
(I screwed up here -- mea culpa -- but let's discuss this in the other thread.)
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.
Right, there's several changes still in your version of ivykis that haven't made it into mine (e.g. to have an abstraction for syslog(), which seems a generally good idea to have, and probably there's more bits as well). Do you think syslog-ng is ready for inclusion into e.g. Fedora as-is, or do you want to get those changes merged into upstream ivykis as well first? cheers, Lennert