Re: RFC: APR 2.0 modularization
"Graham Leggett via dev" <[email protected]>
| Newsgroups | gmane.comp.apache.apr.devel |
|---|---|
| Message-ID | <[email protected]> |
On 22 Apr 2024, at 14:30, Ivan Zhakov <[email protected]> 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 --