lkml.org 
[lkml]   [2018]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-next: build failure after merge of the vfs tree
Hi David,

On Tue, 18 Sep 2018 23:17:21 +0100 David Howells <dhowells@redhat.com> wrote:
>
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > > After merging the vfs tree, today's linux-next build (powerpc
> > > allyesconfig) failed like this:
> > >
> > > samples/vfs/test-fsinfo.c: In function 'fsinfo':
> > > samples/vfs/test-fsinfo.c:37:17: error: '__NR_fsinfo' undeclared (first use in this function); did you mean 'fsinfo'?
>
> I think the problem is that I haven't allocated system call numbers for any
> arches other than x86 - even the x86 syscall numbers are provisional until the
> patchset is taken upstream. I'm not sure of the best way to deal with this -
> make the samples dependent on the X86 arch?

But the sample programs are built with HOSTCC, so you can't depend on
ARCH (since I, for one, am cross compiling). Maybe SUBARCH. Better
would be to use either Kconfig's shell primitive or some make magic to
figure out if the syscall number define's are defined.

> > > samples/vfs/test-fsinfo.c:180:30: warning: format '%llx' expects argument of type 'long long unsigned int', but argument 2 has type '__u64' {aka 'long unsigned int'} [-Wformat=]
> > > printf("\tmax file size: %llx\n", f->max_file_size);
>
> Sigh. On powerpc __u64 is unsigned long, but on x86_64 it's unsigned long
> long. Is it possible to shift all arches to use unsigned long long for __u64?

I doubt it - that would probably cause more warnings in the arch code.
Instead, just explicitly cast it to unsigned long long.
--
Cheers,
Stephen Rothwell
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2018-09-19 01:51    [W:0.104 / U:0.140 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site