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 - XS modules fail to build because <xlocale.h> does not exist
Summary: XS modules fail to build because <xlocale.h> does not exist
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: perl
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1464389 (view as bug list)
Depends On: 1464403
Blocks: TRACKER-bugs-affecting-libguestfs
TreeView+ depends on / blocked
 
Reported: 2017-06-22 19:09 UTC by Jason Tibbitts
Modified: 2017-06-24 06:36 UTC (History)
13 users (show)

Fixed In Version: perl-5.26.0-394.fc27
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-24 06:36:45 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)

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 4 Paul Howarth 2017-06-23 08:12:38 UTC 
Upstream glibc commit:

https://sourceware.org/git/?p=glibc.git;a=commit;h=f0be25b6336db7492e47d2e8e72eb8af53b5506d
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.
Note You need to log in before you can comment on or make changes to this bug.