Bug 554643

Summary: glibc-2.11.90-7 breaks build of ghc
Product: [Fedora] Fedora Reporter: Jens Petersen <petersen>
Component: glibcAssignee: Andreas Schwab <schwab>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: drepper, jakub, mcrha, mjw, schwab, valdis.kletnieks
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: glibc-2.11.90-8 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-01-13 12:43:05 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
config.log none

Description Jens Petersen 2010-01-12 08:54:29 UTC
Description of problem:
After yesterday's build of glibc-2.11.90-7 in dist-f13
the ghc package no longer builds in koji. :-(

eg http://koji.fedoraproject.org/koji/taskinfo?taskID=1916172

Version-Release number of selected component (if applicable):
glibc-2.11.90-7

How reproducible:
every time

Steps to Reproduce:
1. try to build ghc/devel in rawhide with glibc-2.11.90-7
2. revert to glibc-2.11.90-4 and retry
  
Actual results:
1. build fails like above buildlog:
http://koji.fedoraproject.org/koji/getfile?taskID=1916175&name=build.log&offset=-2000
2. build succeeds

Expected results:
1. build to succeed

Additional info:
Perhaps it is better to untag -7 ?

Comment 1 Andreas Schwab 2010-01-12 09:50:25 UTC
Please attach config.log.

Comment 2 Jens Petersen 2010-01-12 10:21:14 UTC
Created attachment 383215 [details]
config.log

This is the config.log just before the error if it helps.

Note that HsBase.h is part of the ghc source and not generated.

HsBaseConfig.hs is unchanged.

Comment 3 Jens Petersen 2010-01-12 10:22:25 UTC
Should be easy to reproduce locally:

$ fedora-cvs ghc
$ cd ghc/devel
$ rpm -q glibc-headers
$ make local

Comment 4 Andreas Schwab 2010-01-12 11:12:09 UTC
*** Bug 554679 has been marked as a duplicate of this bug. ***

Comment 5 Milan Crha 2010-01-12 17:35:40 UTC
When will be the build system updated, or is it already?

Comment 6 Jens Petersen 2010-01-12 21:25:37 UTC
Presumably.  I see glibc-2.11.90-8:

http://koji.fedoraproject.org/koji/buildinfo?buildID=150617

Comment 7 Jens Petersen 2010-01-12 21:33:02 UTC
Thanks

Resubmitted ghc job: http://koji.fedoraproject.org/koji/taskinfo?taskID=1917588

Comment 8 Milan Crha 2010-01-13 11:28:24 UTC
Thanks, evolution-data-server was built, though it failed on evolution itself now, with an error:
> e-mktemp.c: In function 'e_mktemp':
> e-mktemp.c:182: error: implicit declaration of function 'mktemp'
Why is that? I thought the online doc [1] will mention its dropping or deprecation or something, but it isn't. Thus I consider it another bug in a new version. Reopening.

[1] http://www.kernel.org/doc/man-pages/online/pages/man3/mktemp.3.html

Comment 9 Andreas Schwab 2010-01-13 12:43:05 UTC
POSIX.1-2008  removes  the  specification  of mktemp().

Comment 10 Jakub Jelinek 2010-01-13 12:55:59 UTC
Sure, the question is whether we need to be this pedantic even when no strict POSIX 2008 conformance is requested.  In particular, couldn't the condition
be
#if defined __USE_MISC || (defined __USE_XOPEN_EXTENDED && !defined __USE_XOPEN2K)
?
(__USE_GNU implies __USE_MISC I think).  So, for strict -D_POSIX_C_SOURCE=200809L
mktemp wouldn't be defined, but for no feature test macros at all it would?

Comment 11 Andreas Schwab 2010-01-13 15:04:10 UTC
*** Bug 555060 has been marked as a duplicate of this bug. ***

Comment 12 Milan Crha 2010-01-13 16:52:06 UTC
(In reply to comment #10)
> Sure, the question is whether we need to be this pedantic even when no strict
> POSIX 2008 conformance is requested....

I do not care that much. My concern was rather whether it was a typo, like with the above, or intentional change. If it's intentional, then I'm fine with that. And I'm going to rewrite necessary parts with mktemp in evolution anyway.

Comment 13 Valdis Kletnieks 2010-01-13 22:14:30 UTC
I'm confused why bug 555060 having to do with 'struct wait' is flagged as a dup of this one which seems to be about mktemp?

Comment 14 Jens Petersen 2010-01-14 00:34:09 UTC
(In reply to comment #13)
> I'm confused why bug 555060 having to do with 'struct wait' is flagged as a dup
> of this one which seems to be about mktemp?    

No, mktemp is different topic for evo.  Grep attachment in comment 2 for __WAIT_STATUS.