Hi!
The next release of dev-libs/expat is not far away and there are two
things that I would appreciate input with, before the next bump in Gentoo:
-DXML_UNICODE_WCHAR_T issues and Gentoo/Debian mismatch
=======================================================
With USE=unicode, on Gentoo two extra libraries are built:
* libexpatu.so (with CPPFLAGS=-DXML_UNICODE)
* libexpatw.so (with CPPFLAGS=-DXML_UNICODE_WCHAR_T)
^
However, -DXML_UNICODE_WCHAR_T has only ever worked with 2-byte wchar_t,
while 4-byte wchar_t seems mainstream on Linux (and GCC -fshort-wchar
would required libc to have the same, if you actually wanted to pass
those wchar_t strings to wprintf and friends).
So libexpatw.so in Gentoo is not functional at the moment.
To make things worse, Debian has libexpatw.so with
CPPFLAGS=-DXML_UNICODE, which corresponds to current libexpatu.so in
Gentoo, rather than libexpatw.so.
How do you evaluate these options:
a) Keep libexpatu.so + change libexpatw.so to CPPFLAGS=-DXML_UNICODE
b) Drop libexpatu.so + change libexpatw.so to CPPFLAGS=-DXML_UNICODE
Depend on dev-libs/libbsd
=========================
The next release is very likely to add (optional but helpful) support
for arc4random_buf that dev-libs/libbsd provides (especially on systems
with glibc prior to 2.25) [1]. I wonder if Expat's proximity to @system
has any strong implications on whether
A) libbsd should be a default-off use dependency
IUSE="libbsd" RDEPEND="libbsd? ( dev-libs/libbsd )"
B) libbsd could be a default-on use dependency
IUSE="+libbsd" RDEPEND="libbsd? ( dev-libs/libbsd )"
C) libbsd could even go into DEPEND and RDEPEND directly, or
RDEPEND="dev-libs/libbsd"
D) libbsd should not become any kind of future dependency of
dev-libs/expat.
Thanks for your time!
Best
Sebastian
[1] https://github.com/libexpat/libexpat/pull/30
