Created attachment 496790 [details] libxslt-1.1.30-locale-support-glibc-2.26.patch Since version 2.26, glibc removed the 'xlocale.h' header (see [1]). Thus when building libxslt, the configure script fails to find it and disables locale support in libxslt entirely (this can be seen in /usr/include/x86_64-pc-linux-gnu/libxslt/xsltconfig.h, around lines 129-137). Attached is a patch to only include 'xlocale.h' for versions of glibc below 2.26. The patch also touches configure.in to test for locale support even when 'xlocale.h' is missing. Note that I'm a newbie with the autotools, so it may be that the way I did this is not the Right Way To Do It. This issue has been reported upstream, see [2]. [1]: https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.27xlocale.h.27 [2]: https://bugzilla.gnome.org/show_bug.cgi?id=788264
it probably makes more sense to check for and include locale.h instead...
(In reply to Andreas K. Hüttel from comment #1) > it probably makes more sense to check for and include locale.h instead... What do you mean exactly? locale.h is already checked for in the configure.in, and included at the line right above xlocale.h.
Upstream committed a fix for the issue: https://git.gnome.org/browse/libxslt/commit/?id=8b4babb8f742a1a189df4c4569e68eda308df68f
It's actually worse than this. Public xslt headers include xlocale.h
(In reply to Andreas K. Hüttel from comment #4) > It's actually worse than this. Public xslt headers include xlocale.h Yes, sorry I didn't make this clear. This broke the build or disabled some features in another package, but I must admit I can't remember which. The attached patch fixes this.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=22feb6cfb4d502a668287e6cada18bf52d418776 commit 22feb6cfb4d502a668287e6cada18bf52d418776 Author: Andreas K. Hüttel <dilfridge@gentoo.org> AuthorDate: 2017-10-28 20:30:51 +0000 Commit: Andreas K. Hüttel <dilfridge@gentoo.org> CommitDate: 2017-10-28 20:31:09 +0000 dev-libs/libxslt: Fix glibc-2.26 compatibility. Patch by Quentin Minster. This patch is much less intrusive than the upstream solution, so using it for now. Revision bump since the current version unconditionally includes in public headers xlocale.h ... Closes: https://bugs.gentoo.org/632214 Package-Manager: Portage-2.3.13, Repoman-2.3.4 .../libxslt/files/libxslt-1.1.30-glibc226.patch | 32 +++++ dev-libs/libxslt/libxslt-1.1.30-r2.ebuild | 136 +++++++++++++++++++++ 2 files changed, 168 insertions(+)
Perhaps less intrusive, but it breaks on Darwin In file included from /Users/fabian/Gentoo-10.10/var/tmp/portage/dev-libs/libxslt-1.1.30-r2/work/libxslt-1.1.30/libxslt/xslt.c:32: In file included from /Users/fabian/Gentoo-10.10/var/tmp/portage/dev-libs/libxslt-1.1.30-r2/work/libxslt-1.1.30/libxslt/xsltInternals.h:24: /Users/fabian/Gentoo-10.10/var/tmp/portage/dev-libs/libxslt-1.1.30-r2/work/libxslt-1.1.30/libxslt/xsltlocale.h:28:9: error: unknown type name 'locale_t' typedef locale_t xsltLocale; ^
(In reply to Fabian Groffen from comment #7) > Perhaps less intrusive, but it breaks on Darwin > > In file included from > /Users/fabian/Gentoo-10.10/var/tmp/portage/dev-libs/libxslt-1.1.30-r2/work/ > libxslt-1.1.30/libxslt/xslt.c:32: > In file included from > /Users/fabian/Gentoo-10.10/var/tmp/portage/dev-libs/libxslt-1.1.30-r2/work/ > libxslt-1.1.30/libxslt/xsltInternals.h:24: > /Users/fabian/Gentoo-10.10/var/tmp/portage/dev-libs/libxslt-1.1.30-r2/work/ > libxslt-1.1.30/libxslt/xsltlocale.h:28:9: error: unknown type name 'locale_t' > typedef locale_t xsltLocale; > ^ Reopening thus. The best solution would be a version bump. Ping!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e39d23cb4ddf16005e6dc6417c929219bbb16b85 commit e39d23cb4ddf16005e6dc6417c929219bbb16b85 Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2018-04-21 11:23:40 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2018-04-21 12:33:02 +0000 dev-libs/libxslt: bump to 1.1.32 Drop the m4 patch that adds CXXFLAGS with unknown reasons of existing; it shouldn't be necessary as no AC_LANG([C++]) or such is used in configure.ac, so lets try without. simplify-python and python static modules disabling patches are kept for now, just having to adjust for the upstream rename of configure.in to configure.ac xslt-config breakage was fixed upstream in a different way, thus should not need that patch anymore, either. xlocale.h glibc removal was handled differently as well, via AC_CHECK_HEADERS([locale.h xlocale.h]) AC_CHECK_FUNCS([strxfrm_l]) with HAVE_LOCALE_H and HAVE_XLOCALE_H in the installed xsltlocale.h, about which I'm not sure how consumers are supposed to handle it when directly or indirectly including xsltlocale.h (presumably doing their own AC_CHECK_HEADERS call?), but that similar before as well via ifdef XSLT_LOCALE_XLOCALE in 1.1.30. "rm -r .. || die" instead of "rm -rf .." while here and fix unnecessary removal of non-existing non-python examples. There actually is a C example, but not installed (due to requiring ICU), so we'd have to doins it instead with USE=examples, but meh. Due to no -f, python examples have to be removed only if use python. Closes: https://bugs.gentoo.org/632214 Bug: https://bugs.gentoo.org/637310 Package-Manager: Portage-2.3.28, Repoman-2.3.9 dev-libs/libxslt/Manifest | 1 + .../libxslt/files/1.1.32-simplify-python.patch | 250 +++++++++++++++++++++ dev-libs/libxslt/libxslt-1.1.32.ebuild | 123 ++++++++++ 3 files changed, 374 insertions(+)
