Bug 1058258 - FTBFS: /usr/include/gnu/stubs.h:11:30: fatal error: gnu/stubs-64-v1.h: No such file or directory
Summary: FTBFS: /usr/include/gnu/stubs.h:11:30: fatal error: gnu/stubs-64-v1.h: No suc...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: ppc
OS: Linux
medium
high
Target Milestone: ---
Assignee: Siddhesh Poyarekar
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: PPCTracker
TreeView+ depends on / blocked
 
Reported: 2014-01-27 11:09 UTC by Karsten Hopp
Modified: 2016-11-24 12:15 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-02-17 14:54:09 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Karsten Hopp 2014-01-27 11:09:23 UTC
Description of problem:
gcc-4.8.2-13.fc21 fails t o build on PPC:

In file included from /usr/include/features.h:402:0,
                 from /usr/include/stdio.h:27,
                 from ../../../../libgcc/../gcc/tsystem.h:87,
                 from ../../../../libgcc/libgcov.c:27:
/usr/include/gnu/stubs.h:11:30: fatal error: gnu/stubs-64-v1.h: No such file or directory
 # include <gnu/stubs-64-v1.h>
                              ^
compilation terminated.

Version-Release number of selected component (if applicable):
gcc-4.8.2-13.fc21

How reproducible:
always

Steps to Reproduce:
1. ppc-koji build --scratch f21 gcc-4.8.2-13.fc21.src.rpm
2.
3.

Actual results:
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1626338

Expected results:


Additional info:

Comment 1 Jakub Jelinek 2014-01-27 11:26:13 UTC
That is clearly a glibc (and likely also glibc{32,64}) bug.
In the past (and non-ppc* arches) glibc-headers includes /usr/include/gnu/stubs.h
header and glibc-devel includes /usr/include/gnu/stubs-*.h (for the corresponding multilib).
But, gnu/stubs.h has been changed recently apparently on *ppc*, so that it is:
#include <bits/wordsize.h>

#if __WORDSIZE == 32
# include <gnu/stubs-32.h>
#endif
#if __WORDSIZE == 64 && _CALL_ELF != 2
# include <gnu/stubs-64-v1.h>
#endif
#if __WORDSIZE == 64 && _CALL_ELF == 2
# include <gnu/stubs-64-v2.h>
#endif

but /usr/include/gnu/stubs-64-v1.h is included also in glibc-headers*.ppc64.rpm, rather than glibc-devel*.ppc64.rpm.  This means that if you install e.g. glibc-headers*.ppc.rpm and both glibc-devel*.ppc{,64}.rpm, it will be impossible to compile 64-bit apps.
And, the glibc{32,64} hacks needs similar adjustment (basically be regenerated after glibc is fixed).

Comment 3 Siddhesh Poyarekar 2014-01-28 17:57:36 UTC
(In reply to Jakub Jelinek from comment #1)
> That is clearly a glibc (and likely also glibc{32,64}) bug.
> In the past (and non-ppc* arches) glibc-headers includes
> /usr/include/gnu/stubs.h
> header and glibc-devel includes /usr/include/gnu/stubs-*.h (for the
> corresponding multilib).

To be precise, "gnu/stubs-[12364]\+\.h" are included in glibc-devel and clearly "stubs-64-v1.h" doesn't match.  It would be easy to just make it gnu/stubs-.*\+\.h.

I'll work on this.

Comment 4 Siddhesh Poyarekar 2014-01-29 10:52:17 UTC
I have pushed a fix and build to rawhide.  Karsten, could you please verify that the powerpc bits are fixed?  How does one push powerpc builds using fedpkg?

Comment 5 Siddhesh Poyarekar 2014-01-30 09:22:09 UTC
I did a scratch build on ppc:

http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1635759

and verified that stubs-64-v1.h is in glibc-devel and not glibc-headers, so this should be fixed.  Please reopen if gcc still refuses to build with the latest glibc in rawhide.

Comment 6 Karsten Hopp 2014-02-16 10:47:05 UTC
This problem still exists with glibc-2.18.90-27.fc21 :

http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=1667383

gcc build on PPC(32bit) is looking for gnu/stubs-64-v1.h, but that's only in the glibc-devel.ppc64 package

Comment 7 Jakub Jelinek 2014-02-16 10:52:22 UTC
Supposedly glibc32 and glibc64 packages need to be updated.

Comment 8 Karsten Hopp 2014-02-17 14:54:09 UTC
redoing glibc32 and glibc64 packages with the latest glibc fixed this for me, thanks !


Note You need to log in before you can comment on or make changes to this bug.