glibc 2.26 dropped xlocale.h. Packages should just use locale.h instead. NOTE: While above advice works for any glibc, it does not work universally on prefix. Darwin e.g. has no locale.h, but only xlocale.h - you will have to work with #ifdef's if you want to support that.
kde-apps/kdenlive is using xlocale.h, fixed by making symlink from locale.h
(In reply to strobil from comment #1) > kde-apps/kdenlive is using xlocale.h, fixed by making symlink from locale.h I can confirm that =kde-apps/kdenlive-17.12.1 indeed fails due to this error.
Getting issues with this for =app-emulation/virtualbox-5.2.8 as well.
media-libs/mesa also showed this as an issue breaking the “build” or make processing during emerge while building a fresh gentoo installation. I'll be attempting a workaround by deleting this individual file, I'll commemt again if this workaround doesn't solve my own issue
media-libs/mesa-18.0.0_rc5 failure when glibc-2.26 is installed with xlocale.h, the action of “rm /usr/include/xlocale.h” allowed mesa to complete compilation without failures or errors.
(In reply to matoro from comment #3) > Getting issues with this for =app-emulation/virtualbox-5.2.8 as well. Looked into this without a clear win. Appears to be by way of gsoap. Gsoap upstream did something to address this, but I can't figure it out... pretty sure I am just missing the plot somehow. So my impression is that, probably, there should be a gsoap bug for xlocale removal, and although the gsoap xlocale header dependency results in a virtualbox ebuild failure, it's probably not a problem needing to be addressed in the virtualbox ebuild, but in gsoap's, by some combination of backporting, revbumping, and having more of time and/or a clue than I.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3b74cf4bf4f8e2867b5feb531c358bc548405aa5 commit 3b74cf4bf4f8e2867b5feb531c358bc548405aa5 Author: Robin H. Johnson <robbat2@gentoo.org> AuthorDate: 2018-06-06 05:22:13 +0000 Commit: Robin H. Johnson <robbat2@gentoo.org> CommitDate: 2018-06-06 05:24:06 +0000 dev-perl/XML-LibXSLT: newer dev-libs/libxslt for glibc glibc-2.26 no longer ships xlocale.h, and consumers should switch to locale.h instead. dev-libs/libxslt-1.1.32 contains the fix, but we need to make sure it's present before dev-perl/XML-LibXSLT gets rebuilt. Bug: https://bugs.gentoo.org/show_bug.cgi?id=638010 Bug: https://bugs.gentoo.org/637310 Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Package-Manager: Portage-2.3.33, Repoman-2.3.9 dev-perl/XML-LibXSLT/XML-LibXSLT-1.940.0.ebuild | 4 ++-- dev-perl/XML-LibXSLT/XML-LibXSLT-1.950.0.ebuild | 4 ++-- dev-perl/XML-LibXSLT/XML-LibXSLT-1.960.0.ebuild | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-)
Let's close this tracker. glibc 2.25 is masked, 2.26 is stable. What still fails now is a treecleaning candidate.
*** Bug 669360 has been marked as a duplicate of this bug. ***
All virtualbox version fail. Creating an empty xlocale.h allows a rebuild. So the content is not relevant for 5.2.20.