Hi all, I have a question to which some of you may have at least an opinion.
A couple of years ago, I read in several guides and textbooks that there potentially is a problem in this situation: Let a, b be dlloaded modules. Let a.a and b.b be public symbols in these modules, and g.g a public symbol inside rsyslog core (which loads a and b). Now assume code in b wants to access a.a and g.g (so the dlloaded module needs to resolve public symbols inside the core and other dlloaded modules during its load time). Linux handles this without problems, and as it looks Solaris and BSD do as well. However, I was told that there are some platforms which do not support this (AIX? HP-UX?). In order to keep portable, I created a scheme where b (the dlloaded module) queries pointers to all other methods in core and dlloaded modules it needs. This works well, but there is some overhead associated with that. Obviously, there is a (mild) runtime overhead. But it also causes development overhead, as quite some code needs to be written to support that. Looking backward, I have never seen any platform that actually requires that scheme. Even "better", I have not followed it in all cases (some legacy calls) and I never got into any troubles. May be that's just because I don't have AIX and HP-UX and ... The big question is if it really makes sense to continue that way. If we can conclude that the problem this code intends to solve is actually no problem, I could clean up a lot of code and also get some better development productivity in the future. Also, as far as I know, libtool permits static module linking for such cases if a very exotic platform would actually not support the dynaload functionality. So I am pretty tempted to drop that approach and use the Linux dynalinker's capability. Does anyone have concerns about this? Does it sound reasonable? Feedback would deeply be appreciated. Thanks, Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
