Bug 198615 - types.h does not set gid_t/uid_t as defined
types.h does not set gid_t/uid_t as defined
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc-kernheaders (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Woodhouse
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-12 06:53 EDT by kang
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-12 09:04:34 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)

  None (edit)
Description kang 2006-07-12 06:53:28 EDT
Description of problem:
Some packages using Linux kernel headers do not compile

Version-Release number of selected component (if applicable):
3.0-5.2


a normal linux/types.h defines things this way (stock vanilla kernel, and other
Linux distributions):
#ifdef __KERNEL__
[...]
#else
typedef __kernel_uid_t          uid_t;
#define __uid_t_defined
typedef __kernel_gid_t          gid_t;
#define __gid_t_defined
#endif /* __KERNEL__ */

So that uid_t/gid_t are marked as defined.

However, the glibc-kernheaders package do not tell that they are defined (with
#define __g/uid_t_defined).

When you need to include both <linux/types.h> and <unistd.h>, compilation will
fail because the type gets redefined.

If you read the /usr/include/unistd.h file you will find this:

/* The Single Unix specification says that some more types are
   available here.  */
# ifndef __gid_t_defined
typedef __gid_t gid_t;
#  define __gid_t_defined
# endif

# ifndef __uid_t_defined
typedef __uid_t uid_t;
#  define __uid_t_defined
# endif

I did not find why this was changed in Fedora.
Thank you for reading.

External bug reference: http://bugtracker.rsbac.org/view.php?id=76
Comment 1 David Woodhouse 2006-07-12 07:10:39 EDT
(In reply to comment #0)
> Description of problem:
> Some packages using Linux kernel headers do not compile
> 
> Version-Release number of selected component (if applicable):
> 3.0-5.2
> 
> 
> a normal linux/types.h defines things this way (stock vanilla kernel, and 
> other Linux distributions):
> #ifdef __KERNEL__
> [...]
> #else
> typedef __kernel_uid_t          uid_t;
> #define __uid_t_defined
> typedef __kernel_gid_t          gid_t;
> #define __gid_t_defined
> #endif /* __KERNEL__ */

That doesn't match the upstream kernel. See
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;hb=6550e07f41ce8473ed684dac54fbfbd42183ffda;f=include/linux/types.h

> When you need to include both <linux/types.h> and <unistd.h>, compilation will
> fail because the type gets redefined.

Including kernel headers from userspace is generally broken. Please show an
example to justify your usage of <linux/types.h>. Shouldn't <asm/types.h>
generally be sufficient?

> I did not find why this was changed in Fedora.
> Thank you for reading.

Fedora's headers match the upstream kernel in this.
 
> External bug reference: http://bugtracker.rsbac.org/view.php?id=76

Seems to give me a login page.
Comment 2 kang 2006-07-12 08:35:31 EDT
Ok, you're right, linux/ should generally not be included.
Also, it seems to have changed (most distributions still have the #define
__gid.. in linux/types.h too)
probably until packages and so on update.
i switched to asm/types.h + sys/types.h which define the same types anyway.
(asm/types.h wasnt then sufficient)

about the other bugtracker: yes it seems not to allow anonymous access. (beeh)

you may close this bug as invalid, thanks for the quick reply :)
Comment 3 David Woodhouse 2006-07-12 09:04:34 EDT
The upstream kernel (as of 2.6.18-rc1) now has a 'make headers_install' target
which exports sanitised kernel headers. So Fedora doesn't have its own version
of anything now; it's all just taken from upstream. And hopefully the other
distributions will catch up with that shortly, and there'll be _no_ more
inconsistency between distributions.

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