On 20 Apr 2024, at 11:38, Ivan Zhakov <chemo...@gmail.com> wrote:
> In APR 2.0 we merged APR-Util **project** to APR. Which is IMHO a good thing.
At the time, and with time and hindsight, I never understood what the point was
at combining APR and APR-util.
The reason is because...
> But we also merged everything into one big library + modules for loadable
> drivers, if APR_HAVE_MODULAR_DSO.
...of this above.
We moved from a lightweight portable library, and a secondary heavier library
that extended the lightweight library, to one big blob.
> I think it's suboptimal:
> 1. Distributions have to decide what features to compile into this big APR
> library.
> 2. Linking to APR-2 makes applications depend on multiple libraries, even
> this particular application is not going to use them.
This above isn't true - that's what the modules are for.
If any libraries are leaking into APR, that's a bug that needs fixing.
For example:
[minfrin@seawitch ~]# ldd /usr/lib64/libaprutil-1.so
linux-vdso.so.1 (0x00007fff7159e000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f258b619000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f258b5e8000)
libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f258b5ae000)
libapr-1.so.0 => /lib64/libapr-1.so.0 (0x00007f258b56e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f258b200000)
/lib64/ld-linux-x86-64.so.2 (0x00007f258b66b000)
libm.so.6 => /lib64/libm.so.6 (0x00007f258b493000)
None of libuuid, expat or crypt should be linked above.
> I would suggest separating APR in different libraries, while keeping them in
> one project/source tree.
>
> Something like that:
> - apr-2
> - apr-dbd-2
> - apr-dbm-2
> - apr-xlate-2 (?)
> - apr-crypto-2
> - apr-xml-2
> - apr-ldap-2
> - apr-memcache-2
> - apr-redis-2
>
> I want to clarify that I don't propose going back to apr-util time when APR
> was splitted to separate projects: this proposal is only about libraries on
> the disk.
>
> What do you think?
I would first fix any leaking library bigs before trying to change anything.
That said, splitting the above would cause as need for eight different "stub"
libraries, as well as the actual modules themselves, which might get out of
hand.
Regards,
Graham
--
