Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1464244
Summary: | XS modules fail to build because <xlocale.h> does not exist | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Jason Tibbitts <j> |
Component: | perl | Assignee: | Jason Tibbitts <j> |
Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | rawhide | CC: | cweyl, fweimer, iarnell, jplesnik, kasal, paul, perl-devel, ppisar, psabata, rc040203, rjones, tcallawa, zdohnal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | perl-5.26.0-394.fc27 | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2017-06-24 06:36:45 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 1464403 | ||
Bug Blocks: | 910269 |
Description
Jason Tibbitts
2017-06-22 19:09:27 UTC
That 394 release test failure is really troublesome. It has something to do with lexicographic sort of strings but it fails only in mock. I thought it's because of POSIXLY_CORRECT=y in the environment, but I couldn't prove it's really caused by that. I'm still searching for the real cause. Could please write down exactly which glibc release removed the header file? From glibc.spec: * Wed Jun 21 2017 Florian Weimer <fweimer> - 2.25.90-8 - Adjust build requirements for gcc, binutils, kernel-headers. - Auto-sync with upstream master, commit 43e0ac24c836eed627a75ca932eb7e64698407c6, changing: - Remove <xlocale.h> Upstream glibc commit: https://sourceware.org/git/?p=glibc.git;a=commit;h=f0be25b6336db7492e47d2e8e72eb8af53b5506d *** Bug 1464389 has been marked as a duplicate of this bug. *** <xlocale.h> previously said: /* Structure for reentrant locale using functions. This is an (almost) opaque type for the user level programs. The file and this data structure is not standardized. Don't rely on it. It can go away without warning. */ It's an internal glibc header which was installed by accident. Perl should not be including it, and I expect that recompiling Perl will simply undefine I_XLOCALE: #ifdef I_XLOCALE # include <xlocale.h> #endif … Checking to see if you have fpos64_t... <xlocale.h> NOT found. newlocale() found. … I_XLOCALE does not gate anything else AFAICS. *** Bug 1464403 has been marked as a duplicate of this bug. *** I encountered same bug when I build Vim with only difference that error is reported on perl.h header file: /usr/lib64/perl5/CORE/perl.h:738:13: fatal error: xlocale.h: No such file or directory # include <xlocale.h> ^~~~~~~~~~~ compilation terminated. To summarize the state of things: This simply requires a rebuild of perl. However, that rebuild fails in the dest suite because of an unrelated issue in glibc. A patch has been created for that unrelated problem; here's what needs to happen * The glibc patch gets acked by upstream. * That patch gets pulled into the rawhide glibc package and glibc is rebuilt. * The glibc update gets signed and things are updated so that it's pulled into rawhide buildroots. * Perl can be rebuilt successfully. It will detect that xlocale.h isn't available and not set up the internal config.h to use it. * That update gets signed and pulled into rawhide buildroots. * arch-dependent perl packages will start building again. The glibc patch is at https://sourceware.org/ml/libc-alpha/2017-06/msg01193.html Florian has graciously offered to push it into a Fedora package if it doesn't get reviewed quickly by upstream. I wouldn't bet on being able to do successful XS module builds until next week unless the stars and timezones align, or someone's working over the weekend. (In reply to Jason Tibbitts from comment #9) > I wouldn't bet on being able to do successful XS module builds until next > week unless the stars and timezones align, or someone's working over the > weekend. glibc-2.25.90-15.fc27 should fix this issue. I'll be around later, when the build completes, but I can't trigger a perl rebuild because I'm not a perl maintainer or provenpackager. Actually anyone can trigger a koji build; you only need the extra privileges to commit things. The glibc build is nearly complete now and after it's done I'll wait a bit to make sure that it has settled into the rawhide buildroots and then I'll go ahead and just resubmit the last failed Perl build. Git head is unchanged at d3e98ce2042e254d0c1118ba97ccc7ff6bfa7c05 so this should cause no issues that wouldn't have been caused if the glibc bug hadn't tripped up the test suite. OK, the perl build is complete and has made it into the rawhide buildroots. I've verified that I no longer have the xlocale.h problem, and that at least my test case is fine. |