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: perlAssignee: Jason Tibbitts <j>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: 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
A recent glibc build in rawhide has removed /usr/include/xlocale.h completely.  But the current rawhide perl still has a config.h which includes:

#define I_XLOCALE               /**/

Which means that perl.h will do:

#ifdef I_XLOCALE
#   include <xlocale.h>
#endif

And this causes the following build failure for me, and I suspect other arch-specific Perl modules, to fail to build:

make[2]: Entering directory '/builddir/build/BUILD/cyrus-imapd-3.0.2/perl/imap'
gcc -c  -I../.. -I../../com_err/et   -I../../perl/imap -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -fwrapv -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g   -DVERSION=\"1.00\" -DXS_VERSION=\"1.00\" -fPIC "-I/usr/lib64/perl5/CORE"  -DPERL_POLLUTE IMAP.c
make[2]: Leaving directory '/builddir/build/BUILD/cyrus-imapd-3.0.2/perl/imap'
In file included from IMAP.xs:49:0:
/usr/lib64/perl5/CORE/perl.h:738:13: fatal error: xlocale.h: No such file or directory
 #   include <xlocale.h>
             ^~~~~~~~~~~
compilation terminated.
make[2]: *** [Makefile:353: IMAP.o] Error 1

I would guess that Perl just needs a rebuild to stop defining I_XLOCALE but the most recent build (release 394) did not complete due to a failing test.  And I sure hope this doesn't change the ABI....

Comment 1 Petr Pisar 2017-06-23 06:35:50 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.

Comment 2 Petr Pisar 2017-06-23 06:37:32 UTC
Could please write down exactly which glibc release removed the header file?

Comment 3 Ralf Corsepius 2017-06-23 07:16:56 UTC
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>

Comment 5 Richard W.M. Jones 2017-06-23 10:19:01 UTC
*** Bug 1464389 has been marked as a duplicate of this bug. ***

Comment 6 Florian Weimer 2017-06-23 11:46:41 UTC
<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.

Comment 7 Florian Weimer 2017-06-23 12:09:46 UTC
*** Bug 1464403 has been marked as a duplicate of this bug. ***

Comment 8 Zdenek Dohnal 2017-06-23 14:51:44 UTC
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.

Comment 9 Jason Tibbitts 2017-06-23 15:20:00 UTC
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.

Comment 10 Florian Weimer 2017-06-23 15:46:21 UTC
(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.

Comment 11 Jason Tibbitts 2017-06-23 17:34:00 UTC
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.

Comment 12 Jason Tibbitts 2017-06-23 20:33:16 UTC
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.