On 22 Apr 2024, at 14:30, Ivan Zhakov <i...@apache.org> wrote: > Can you confirm why xlate/iconv cannot be moved to a module? (No expectation > for you to do such a move, just want to understand what makes it impossible). >> > I think it can be done in theory, but I see potential problem: API should be > changed or some kind of implicit initialization should be implemented. > > The same situation with xml API.
My understanding from working on this over the years is that there are layers of archeology. The very first external libraries as I recall were libxml2/expat and iconv, and these were tightly bound. Then modular DSO became a thing, and so DBD/DBM/etc came along with various levels of sophistication. In theory, making libxml2/expat modular should be straightforward, it involves going back and making the old work like the new. > Another benefit of modular approach is that if you link to apr-xlate-2 or to > apr-xml-2 you do not need to handle dynamic DSO load failures. You would still need to handle failure in the choice of ibxml2 or expat. >> If you've disabled modular DSO, you've disabled the split of dependent >> libraries into separate modules. If this is a problem, re-enable modular DSO? > There are two things: APR modular DSO support and support for DSO itself. > Modular DSO can be disabled while keeping support for dynamic build. APR > modular support is configured at compile time and can be disabled by the > distribution maintainer. It can be disabled by a distribution maintainer, why would they do so though? In light of what happened with xz, having the ability to harden a library at runtime by not-loading-unless-necessary is a very good thing, and you'd need a very good reason to turn that off. Regards, Graham --
