All of lore.kernel.org
 help / color / mirror / Atom feed
* Cross-compiling xfsprogs 3.2.x
@ 2015-08-07 12:25 Detlef Vollmann
  2015-08-07 23:15 ` Dave Chinner
  0 siblings, 1 reply; 2+ messages in thread
From: Detlef Vollmann @ 2015-08-07 12:25 UTC (permalink / raw)
  To: xfs

Cross-compiling xfsprogs 3.2.4 gives an error:
./gen_crc32table: cannot execute binary file: Exec format error
This makes sense as a binary built for the target can't run on
the build host.
Working around that isn't hard, however there's no way to run
crc32selftest sensibly and I have no idea whether tables built
on a little-endian 64-bit host will run on a big-endian 32-bit...

Also, I get nervous if I see all the warnings like:
readdir.c:77:2: warning: format '%lx' expects argument of type 'long unsigned int', but argument 2 
has type '__off64_t' [-Wformat=]
   printf(" d_off: 0x%08lx", dirent->d_off);


Any ideas?
   Detlef

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Cross-compiling xfsprogs 3.2.x
  2015-08-07 12:25 Cross-compiling xfsprogs 3.2.x Detlef Vollmann
@ 2015-08-07 23:15 ` Dave Chinner
  0 siblings, 0 replies; 2+ messages in thread
From: Dave Chinner @ 2015-08-07 23:15 UTC (permalink / raw)
  To: Detlef Vollmann; +Cc: xfs

On Fri, Aug 07, 2015 at 02:25:08PM +0200, Detlef Vollmann wrote:
> Cross-compiling xfsprogs 3.2.4 gives an error:
> ./gen_crc32table: cannot execute binary file: Exec format error
> This makes sense as a binary built for the target can't run on
> the build host.
> Working around that isn't hard, however there's no way to run
> crc32selftest sensibly and I have no idea whether tables built
> on a little-endian 64-bit host will run on a big-endian 32-bit...

At this point, we have to trust the cross compiler not to have bugs.
Unfortuantely, this is a bad deal, because we know that various
cross-compilers (e.g. gcc 4.6/4.7 on intel host to arm target)
generate broken code that results in directory corruption....

As for it failing to execute and stopping the build, that should be
fixed in 4.2.0-rc1 (current head of the git tree here:
git://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git).

> Also, I get nervous if I see all the warnings like:
> readdir.c:77:2: warning: format '%lx' expects argument of type 'long
> unsigned int', but argument 2 has type '__off64_t' [-Wformat=]
>   printf(" d_off: 0x%08lx", dirent->d_off);

Which is correct on 64 bit machines as glibc defines __off64_t to a
long int on 64 bit platforms. On 32 bit platforms it is "long long
int" and that's why we have those "PRIu64" formatting strings
throughout the code base. e.g. in xfs_repair:

$ git grep PRIu64 repair |wc -l
372

there are 372 instances of PRIu64 being used to handle this sort of
problem. There are always going to be new ones pop up as 32 bit
systems are not the primary development target. I'll happily take
patches to silence these warnings on your 32 bit builds (and any
other problems you find)...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-08-07 23:15 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-07 12:25 Cross-compiling xfsprogs 3.2.x Detlef Vollmann
2015-08-07 23:15 ` Dave Chinner

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.