xfsprogs: is it one issue?

xfsprogs: is it one issue?

[Zhi Yong Wu]

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

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

Re: xfsprogs: is it one issue?

[Michael L. Semon]

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

Re: xfsprogs: is it one issue?

[Eric Sandeen]

On 5/25/13 11:29 AM, 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

For starters, which version of xfsprogs?  And what version of kernel headers?

-Eric

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

Re: xfsprogs: is it one issue?

[Zhi Yong Wu]

HI,

xfsprogs should be latest, Last year i tried it, and it worked well,
and today pull the latest one and want to replay with it, but fail.
below are the logs on two different boxes:

[root@f15 xfsprogs]# git describe
v3.1.11-8-g8e78288
[root@f15 xfsprogs]# uname -r
3.6.6-rc1+

Also i also tried this on another box:
[root@f17 xfsprogs]# git describe
v3.1.11-8-g8e78288
[root@f17 xfsprogs]# uname -r
3.9.0-rc1+


On Sun, May 26, 2013 at 5:07 AM, Eric Sandeen <sandeen@sandeen.net> wrote:
> On 5/25/13 11:29 AM, 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
>
> For starters, which version of xfsprogs?  And what version of kernel headers?
>
> -Eric
>



-- 
Regards,

Zhi Yong Wu

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

Re: xfsprogs: is it one issue?

[Zhi Yong Wu]

Yes, now xfsprogs can be compiled and installed well, but xfstests is
still failed to build.

[root@f15 xfstests]# make
loggen.c: In function 'loggen_unmount':
loggen.c:137:9: error: 'xlog_rec_header_t' has no member named 'h_chksum'
loggen.c: In function 'loggen_empty':
loggen.c:205:9: error: 'xlog_rec_header_t' has no member named 'h_chksum'
gmake[3]: *** [loggen] Error 1
gmake[2]: *** [src] Error 2
make[1]: *** [default] Error 2
make: *** [default] Error 2



On Sun, May 26, 2013 at 3:43 AM, Michael L. Semon <mlsemon35@gmail.com> wrote:
> 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



-- 
Regards,

Zhi Yong Wu

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

Re: xfsprogs: is it one issue?

[Zhi Yong Wu]

I remove the lines related to h_chksum, then it can work well, so i
guess that i should send out one patch to fix it.

On Sun, May 26, 2013 at 6:57 AM, Zhi Yong Wu <zwu.kernel@gmail.com> wrote:
> Yes, now xfsprogs can be compiled and installed well, but xfstests is
> still failed to build.
>
> [root@f15 xfstests]# make
> loggen.c: In function 'loggen_unmount':
> loggen.c:137:9: error: 'xlog_rec_header_t' has no member named 'h_chksum'
> loggen.c: In function 'loggen_empty':
> loggen.c:205:9: error: 'xlog_rec_header_t' has no member named 'h_chksum'
> gmake[3]: *** [loggen] Error 1
> gmake[2]: *** [src] Error 2
> make[1]: *** [default] Error 2
> make: *** [default] Error 2
>
>
>
> On Sun, May 26, 2013 at 3:43 AM, Michael L. Semon <mlsemon35@gmail.com> wrote:
>> 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
>
>
>
> --
> Regards,
>
> Zhi Yong Wu



-- 
Regards,

Zhi Yong Wu

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

Re: xfsprogs: is it one issue?

[Dave Chinner]

On Sun, May 26, 2013 at 12:29:11AM +0800, 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

Install the latest kernel headers package for your distro.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: xfsprogs: is it one issue?

[Dave Chinner]

On Mon, May 27, 2013 at 08:44:49AM +1000, Dave Chinner wrote:
> On Sun, May 26, 2013 at 12:29:11AM +0800, 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
> 
> Install the latest kernel headers package for your distro.

Actually, on debian it's part of a libc-dev package:

$ grep -r umode /usr/include |head -1
/usr/include/asm-generic/types.h:typedef unsigned short umode_t
$ apt-file search /usr/include/asm-generic/types.h
linux-libc-dev: /usr/include/asm-generic/types.h
$

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: xfsprogs: is it one issue?

[Dave Chinner]

On Sun, May 26, 2013 at 07:11:03AM +0800, Zhi Yong Wu wrote:
> I remove the lines related to h_chksum, then it can work well, so i
> guess that i should send out one patch to fix it.

While it will make the code in loggen work the same (it just writes
0 to the field but the buffer is already zeroed) as it does now,
it doesn't necessarily mean it works correctly. The current kernels
validate the CRC and throw warnings if the CRC isn't correct, and
CRC enabled kernels will simply refuse to mount.

As it is, my test systems don't build loggen because
HAVE_XLOG_ASSIGN_LSN isn't set by configure. It only gets set if
there's an xfs/libxfs.h header file found in an include path. My
guess is that you've run 'make install-qa' in the xfsprogs package
at some time in the past, and that's why loggen is trying to be
built.

So Michael's quick hack to remove it just to make it compile at this
point is probably appropriate...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

Re: xfsprogs: is it one issue?

[Zhi Yong Wu]

[-- Attachment #1.1: Type: text/plain, Size: 1184 bytes --]

ah, another way by not building-in loggen, thanks.


On Mon, May 27, 2013 at 7:11 AM, Dave Chinner <david@fromorbit.com> wrote:

> On Sun, May 26, 2013 at 07:11:03AM +0800, Zhi Yong Wu wrote:
> > I remove the lines related to h_chksum, then it can work well, so i
> > guess that i should send out one patch to fix it.
>
> While it will make the code in loggen work the same (it just writes
> 0 to the field but the buffer is already zeroed) as it does now,
> it doesn't necessarily mean it works correctly. The current kernels
> validate the CRC and throw warnings if the CRC isn't correct, and
> CRC enabled kernels will simply refuse to mount.
>
> As it is, my test systems don't build loggen because
> HAVE_XLOG_ASSIGN_LSN isn't set by configure. It only gets set if
> there's an xfs/libxfs.h header file found in an include path. My
> guess is that you've run 'make install-qa' in the xfsprogs package
> at some time in the past, and that's why loggen is trying to be
> built.
>
> So Michael's quick hack to remove it just to make it compile at this
> point is probably appropriate...
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>



-- 
Regards,

Zhi Yong Wu

[-- Attachment #1.2: Type: text/html, Size: 1774 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: xfsprogs: is it one issue?

[Zhi Yong Wu]

[-- Attachment #1.1: Type: text/plain, Size: 1183 bytes --]

It has been solved based on your suggestion, thanks


On Mon, May 27, 2013 at 6:48 AM, Dave Chinner <david@fromorbit.com> wrote:

> On Mon, May 27, 2013 at 08:44:49AM +1000, Dave Chinner wrote:
> > On Sun, May 26, 2013 at 12:29:11AM +0800, 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
> >
> > Install the latest kernel headers package for your distro.
>
> Actually, on debian it's part of a libc-dev package:
>
> $ grep -r umode /usr/include |head -1
> /usr/include/asm-generic/types.h:typedef unsigned short umode_t
> $ apt-file search /usr/include/asm-generic/types.h
> linux-libc-dev: /usr/include/asm-generic/types.h
> $
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com
>



-- 
Regards,

Zhi Yong Wu

[-- Attachment #1.2: Type: text/html, Size: 1828 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

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

Re: xfsprogs: is it one issue?

[Arkadiusz Miśkiewicz]

Dave Chinner wrote:

> On Mon, May 27, 2013 at 08:44:49AM +1000, Dave Chinner wrote:
>> On Sun, May 26, 2013 at 12:29:11AM +0800, 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
>> 
>> Install the latest kernel headers package for your distro.
> 
> Actually, on debian it's part of a libc-dev package:
> 
> $ grep -r umode /usr/include |head -1
> /usr/include/asm-generic/types.h:typedef unsigned short umode_t
> $ apt-file search /usr/include/asm-generic/types.h
> linux-libc-dev: /usr/include/asm-generic/types.h
> $

This won't work on recent kernels. Recent kernels export sanitized headers - it's called UAPI .

>From irc conversation:

00:07 < arekm> anyway current kernels export uapi headers (aka user space api headers,
https://lwn.net/Articles/507794/) and these don't export things like umode_t -
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/asm-generic/types.h 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/asm-generic/int-ll64.h
00:10 < bpm> arekm, linux/types.h has it on 3.10
00:10 < arekm> bpm: yes but this is not userspace installed header. it's kernel only
00:11 < arekm> bpm: linux-*/include/uapi/asm-generic/types.h is the one being installed for userspace



-- 
Arkadiusz Miśkiewicz, arekm / maven.pl

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