On Fri, Dec 10, 2021 at 01:58:28PM -0500, przemek klosowski via devel wrote: > On 12/10/21 09:13, Zbigniew Jędrzejewski-Szmek wrote: > >On Fri, Dec 10, 2021 at 10:40:33AM +0100, Vitaly Zaitsev via devel wrote: > > What happens if these libraries are not installed an cannot be dl-opened? > >The functionality that requires those libraries will not be available. > > This is quite clever, +1. > > It occurred to me that a downside might be in mysterious functionality > variances in case of latent bugs. Say, something happens to libpcre2 (file > gets damaged, or ABI incompatibility creeps in, etc) so that suddenly > 'journalctl --grep' stops working. How would one find out about the cause? > From reading the journalctl code, it seems to me that > pcre2-dlopen.c:dlopen_pcre2() is called when --grep is used, and it logs the > failure, which I think addresses my concern. > > So the apps using this technique would have to be written carefully, to only > dlopen() (and therefore also print possible error messages) when the > optional functionality is called for, right? If the dlopen()s were just > shotgunned at the startup, it could result in a lot of chatter. In general, we do this because we think the advantages outweigh the issues, but this does mean that we're happy with the implementation. Right now the function signatures are copied into our code, and there's boilerplate code, and in general the whole system is a bit clunky. In practice it works fine because the libraries we link to are stable system libraries that just don't break API or ABI compatibility. We also import just a handful of symbols. But this is not a general solution — it'd be horrible for any library whose API evolves or many functions need to be used. Ideally, we would have support in the linker to do this automatically. We would specify that certain libraries should be linked weakly, and the linker or compiler would generate stubs that'd be resolved to either NULL or the actual symbol at runtime. I.e. just like calling statically or dynamically linked libraries requires no modifications in the code, and is entirely handled by linker commandline options. > If this technique became widely used, as it probably should, maybe there > ought to be a common way of finding out what is and isn't available. For > instance, the apps could have a special common option, like 'journalctl > --capabilities' returning > > ... > > libpcre2 loaded, --grep enabled > > libfancy NOT loaded, --FANCY disabled That's a reasonable request. Right now it'd need to be implemented manually, i.e. we'd need to remember that e.g. journalctl --grep dlopens libpcre2, and add call the same load function in the function implementing --capabilities. This is certainly doable, but I hope we could make this all more automatic… Maybe we should just add this --version output. It already prints +SUPPORTED -UNSUPPORTED. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
