Hello all, I am porting rsyslog (latest) to an embedded OS that does not support shared libraries or dynamic linking at all. My system does not provide dlopen()/dlsym() and friends, and my toolchain does not create .so's in the first place, so my porting effort is having to update the sources around these limitations. Due to the fundamental design of the core rsyslog runtime, this is turning out to be a challenge, and it would be great if someone can help out with my questions and point me in the right direction. Please bear with the long email.
Background: This port is intended to be very small, and only the default bare minimum modules that are not automatically statically built into rsyslogd (i.e., such as zlibw, regexp, net/netstrms/strmsrv/nsd_ptcp, tcpsrv/tcpclt, imtcp, imuxsock, etc.) are required apart from default statically built-in ones (i.e., omfwd, omfile, ompipe, etc.). Nothing else. Naturally, I am aiming to link the aforementioned "not built-in by default" modules statically with my rsyslogd, and hoping to support corresponding functionalities. Build: I have already obtained a build of rsyslog for my intended configuration with "... --enable-static --disable-shared --enable-rsyslogd --disable-rsyslogrt --enable-inet ..." (and ALL extra plugins are --disable'd). I made the following source changes during the build (apart from minor porting edits appropriate for my system): * In runtime/modules.c, I "fake" a situation as if the dlopen() / dlsym() (APIs nonexistent in my OS) have failed and return error/NULL. I would never specify a module that I do not support (i.e., statically build into my rsyslogd) in the rsyslog.conf, so I did not expect this code to be executed in the first place. (But it does; see below.) * In all the "not statically built in by default" modules, I have added the suitable argument to the BEGINmodInit() macro. Error on launch: When I execute this rsyslogd in my OS environment, it fails and exits immediately upon startup (error code 2066). Apparently, 'conf' wants to load and init the 'net' module. I intended for my built liblmnet.a to be statically linked into my rsyslogd, but still it searches for 'lmnet.so' to try and dlopen() it, and as explained above this errors out. Investigation and questions (and some ideas): 1. Running 'nm' on built rsyslogd shows that liblmnet.a / liblmnsd_ptcp.a / libimtcp.a / etc. modules are not getting statically linked into it at all. May be I need to edit tools/Makefile appropriately and make that happen? 2. Is the dlopen() / dlsym() code in runtime/modules.c somehow unavoidable even if those modules are statically built into rsyslogd? Instead of faking an error situation, should I detect the requested aforementioned module and manually call its modInit() function (once they are statically linked in) in there, and setup some data structures by hand to fake as if dlopen() / dlsym() mechanism actually succeeded? Again, it would be great if someone with the core design knowledge could help me out with this. Thanks and regards, Satyam Sharma _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.