Bug 244336 - failed to build btrfsck in btrfs-progs package
Summary: failed to build btrfsck in btrfs-progs package
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
(Show other bugs)
Version: 7
Hardware: i386 Linux
low
low
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-15 05:43 UTC by Terje Røsten
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-15 08:01:55 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Terje Røsten 2007-06-15 05:43:18 UTC
Description of problem:

Wanted to play with btrfs:

http://oss.oracle.com/~mason/btrfs/

on a rawhide box, however the btrfsck tools will not build.

After some testing it  seems like it will build on Fedora Core 6, but not
on Fedora 7 or rawhide. The error I get is:

gcc -g -Wall -fno-strict-aliasing -Werror -c btrfsck.c
In file included from /usr/include/fcntl.h:38,
                 from btrfsck.c:23:
/usr/include/sys/stat.h:370: error: array type has incomplete element type

As Fedora 7 and rawhide has newer glibc, the problem might be here.


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

glibc-2.6-3
gcc-4.1.2-12

How reproducible:

Download btrfs-progs and try to build on Fedora 7 or rawhide.

http://oss.oracle.com/~mason/btrfs/btrfs-progs-0.2.tar.bz2

Comment 1 Jakub Jelinek 2007-06-15 08:01:55 UTC
btrfsck.c is just buggy:
#define _XOPEN_SOURCE 500
#include <stdio.h>
#include <stdlib.h>
#define __USE_GNU
#include <fcntl.h>

__USE_GNU macro is glibc implementation detail, no program must ever touch it.
See
info libc 'Feature Test Macros'
The feature test macros (_*_SOURCE) must be defined before including any header.
In this case SUSv3 namespace is not enough, as they want the readahead prototype.
But #define __USE_GNU is a wrong way to choose it, the right way is to
#define _GNU_SOURCE 1
above the first included header (either instead of _XOPEN_SOURCE 500 or together
with it).


Comment 2 Terje Røsten 2007-06-15 08:39:42 UTC
Thanks Jakub!


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