| Summary: | [TRACKER] Packages using xlocale.h (and thus failing to build with >=sys-libs/glibc-2.26) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andreas K. Hüttel <dilfridge> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED OBSOLETE | ||
| Severity: | normal | CC: | fturco, krinpaus, leonchik1976, matoro_bugzilla_gentoo, mlspamcb, tsmksubc |
| Priority: | Normal | Keywords: | Tracker |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 628750, 628754, 632214, 634152, 635088, 636206, 637310, 637350, 638082, 638238, 638846, 639108, 645400, 645564, 652626, 652738 | ||
| Bug Blocks: | 628768 | ||
|
Description
Andreas K. Hüttel
2017-11-18 12:56:03 UTC
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. |