[Top] [All Lists]

Re: xfsprogs: is it one issue?

To: Zhi Yong Wu <zwu.kernel@xxxxxxxxx>
Subject: Re: xfsprogs: is it one issue?
From: "Michael L. Semon" <mlsemon35@xxxxxxxxx>
Date: Sat, 25 May 2013 15:43:06 -0400
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=bOCWoeQmf1pk7ic1zBEPMEN/k0T2c/LG1GghTdGoNiw=; b=xEnQSksSIzLMZrLz3RM1gvoT6l46LFUXrFUL4cWNvtVfHNn8Lcu6FKfCPSRnt4ZVMe +mKhTnHztwiIwgAT0OjLOIY7Hfco/022MftPDd9ub9iLZYla7Z+M03KR/DYJaOo1rZgL lsRzRUFVG87NQBDpbEdwH/FoV8bl+SAYYve9FOfIZtoNoxZG4Aa6a5YSuVL5wuMWM4eL u+ieYLFVN5kWPuqZ6H3WGd/sBS5jkR6p4fzzDxge+U8KLtBJrLoSJ6kiyCF5JZ8CbRKF YpVVOzZsgMssE4eRWOZ96SEoTlYCk4R1Z7eQukr8R2OHm5CCFXxSmBFyhLsmRON5hVOA MtHg==
In-reply-to: <CAEH94LjnVn-uD6cfwOcChC4wq1PppcD8BN30F93SD=YjdTbbuw@xxxxxxxxxxxxxx>
References: <CAEH94LjnVn-uD6cfwOcChC4wq1PppcD8BN30F93SD=YjdTbbuw@xxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
On 05/25/2013 12:29 PM, Zhi Yong Wu wrote:

Did anyone hit this issue?

[root@f15 xfsprogs]# make
Building include
Building libxfs
     [TEST]    CRC32
In file included from ../include/libxfs.h:584:0,
                  from crc32.c:36:
../include/xfs/xfs_ialloc.h:75:2: error: unknown type name ‘umode_t’
gmake[2]: *** [crc32selftest] Error 1
gmake[1]: *** [libxfs] Error 2
make: *** [default] Error 2


Zhi Yong Wu

Yes. I've been getting around it by inserting the following in one of the two files above, perhaps in xfs_ialloc.h...

typedef unsigned short umode_t;

It's something in the private kernel headers that doesn't get exported to the public headers by `make headers_install` from the kernel build...at least not for the 3.9 kernel series and later, maybe 3.8 as well. However, I've been told that umode_t is in the Debian 2.6 kernel headers. The main questions here are 1) when did umode_t go away? and 2) what is the proper solution? I use slackware-current, which is unaltered in many places where other distros would add extra tweaks, so it may not be a good reference distribution in this case.

If you mention your distribution and have an idea of which kernel version made the headers in /usr/include/linux, it might help the pros here come up with a solutio...or at least tell the people in charge of the public headers that they might export umode_t.



<Prev in Thread] Current Thread [Next in Thread>