Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report. Summary: Review Request: elektra https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187430 ------- Additional Comments From pertusus@xxxxxxx 2006-04-19 05:36 EST ------- (In reply to comment #19) > I guess, I can't avoid to more direct: The amount of warnings qualifies this > piece of SW as "not ready for public use". > > I would be willing to ignore them for an arbirary standard library, but I am not > willing to ignore them for a package using DLLs, being involved into booting. No software is forced to use elektra for booting. It will take years before stable elements of the booting process use elektra, if it ever happens. However for new elements in boot process I think it is not problematic if they use an experimental piece of software - even if only for testing. > Yes, these packages are also suffering from DLL hell. In particular, packaging > firefox/mozilla plugins is a PITA because of this. I am pretty unclear on the subject, but I can't see how this may be avoided. For non dlopended modules the library must be present during linking, and that's what is avoided with dlopened modules. Do you mean that dlopened modules should have a soname? But lt_dlopenext (and dlopen) don't care about sonames? The only way I see to achieve it would be to hardcode the version in the module name. So it seems to me that it would be misleading to have a version information in the file name similar with what is done for classical shared libraries when it is ignored. The versioning still may be achieved at runtime, by searching for some symbols that would be present only for a given version, or use values stored in variables to make sure that the backend version uses a given api version. From a quick glance at the backend code this doesn't seems to be implemented in elektra. But I do agree with you that it won't solve the trouble for the packagers to make sure that, at package install time the abi/api is the right one. What solution do you have, that allows the flexibility of dlopened modules while allowing to have a abi/api check at package? I see one, it is to have the backend link against a specific libelektra library version. But it is rather ugly. > But there still is a major difference between these packages and elektra: > They install their DLLs into /lib/<subdir> rsp. /usr/lib/<subdir>/plugins. That I agree completly with (as can be ssen in my other comments...). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.