Bug 110655 – param.h should include <unistd.h>

Bug 110655 - param.h should include <unistd.h>

Summary:	param.h should include <unistd.h>

Status:	CLOSED RAWHIDE

Aliases:	None

Product:	Fedora
Classification:	Fedora
Component:	glibc-kernheaders (Show other bugs)
Sub Component:
Version:	1
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Arjan van de Ven
QA Contact:	Brian Brock
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2003-11-22 05:31 EST by Ling Li
Modified:	2007-11-30 17:10 EST (History)
CC List:	0 users

See Also:
Fixed In Version:	2.4-8.41
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2004-04-27 17:18:05 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Ling Li 2003-11-22 05:31:21 EST

Description of problem:
/usr/include/asm/param.h (included in glibc-kernheaders-2.4-8.36)
defines HZ as sysconf(_SC_CLK_TCK) but doesn't include unistd.h, where
the _SC_CLK_TCK is defined. This at least breaks the compilation of
graphviz 1.10.

To Fix: apply this patch

@@ -2,6 +2,7 @@
 #define _ASMi386_PARAM_H

 #ifndef HZ
+#include <unistd.h>
 #define HZ sysconf(_SC_CLK_TCK)
 #endif


Version-Release number of selected component (if applicable):
glibc-kernheaders-2.4-8.36

How reproducible:



Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Greg Schafer 2003-12-11 00:01:24 EST

I'd like to make the observation that this change (now appearing in
glibc-kernheaders-2.4-8.41) breaks the compilation of inetutils-1.4.2
from ftp.gnu.org

revoke.c:15: error: conflicting types for `revoke'
/usr/include/unistd.h:810: error: previous declaration of `revoke'
make[2]: *** [revoke.o] Error 1

This would suggest that the change may be bogus. Or it may just mean
the inetutils package is broken.

Comment 2 Arjan van de Ven 2003-12-11 02:33:56 EST

inetutils is broken I suspect; after all why include a private kernel
header if you can't deal with a posix namespace...

Comment 3 Greg Schafer 2003-12-11 07:01:09 EST

Yep, I've looked into it a bit deeper. Your suspicions are correct.
This header change just exposed a latent bug in inetutils methinks.
Every other package I've compiled so far has been fine. Sorry for
wasting your time.

Comment 4 Ling Li 2004-04-27 17:18:05 EDT

This issue has been fixed in glibc-kernheaders from at least release
2.4-8.41.

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