All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael L. Semon" <mlsemon35@gmail.com>
To: Zhi Yong Wu <zwu.kernel@gmail.com>
Cc: xfs@oss.sgi.com
Subject: Re: xfsprogs: is it one issue?
Date: Sat, 25 May 2013 15:43:06 -0400	[thread overview]
Message-ID: <51A1144A.4020600@gmail.com> (raw)
In-Reply-To: <CAEH94LjnVn-uD6cfwOcChC4wq1PppcD8BN30F93SD=YjdTbbuw@mail.gmail.com>

On 05/25/2013 12:29 PM, Zhi Yong Wu wrote:
> HI,
>
> 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
>
>
> --
> Regards,
>
> 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.

Thanks!

Michael

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-05-25 19:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-25 16:29 xfsprogs: is it one issue? Zhi Yong Wu
2013-05-25 19:43 ` Michael L. Semon [this message]
2013-05-25 22:57   ` Zhi Yong Wu
2013-05-25 23:11     ` Zhi Yong Wu
2013-05-26 23:11       ` Dave Chinner
2013-05-27  1:16         ` Zhi Yong Wu
2013-05-25 21:07 ` Eric Sandeen
2013-05-25 22:46   ` Zhi Yong Wu
2013-05-26 22:44 ` Dave Chinner
2013-05-26 22:48   ` Dave Chinner
2013-05-27  1:17     ` Zhi Yong Wu
2013-06-07 22:31     ` Arkadiusz Miśkiewicz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51A1144A.4020600@gmail.com \
    --to=mlsemon35@gmail.com \
    --cc=xfs@oss.sgi.com \
    --cc=zwu.kernel@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.