[PATCH] build: don't execute statfs and f_fsid checks

Gustavo Zacarias gustavo at zacarias.com.ar
Fri Feb 7 12:12:44 MST 2014


On 02/07/2014 03:25 PM, Andrew Bartlett wrote:

> RETURN VALUE
>        On success, zero is returned.  On error, -1 is returned, and
> errno is set appropriately.
> 
>> Nobody knows what f_fsid is supposed to contain (but see below).
> 
> Sure, it isn't a firm standard, but where the behaviour is known, it is
> well known. 

For f_fsid the test is doing nothing with it, so there's no need to
execute it.
And for statfs you're basically checking that it works by executing it,
the only caveat i can think of is some unix having a broken statfs where
you'd want to execute the test but it would seem very odd for such a
common syscall.
The BSDs seem to use a different structure according to the manpage,
FreeBSD says:
http://www.freebsd.org/cgi/man.cgi?query=statfs&sektion=2
but it's definitely compatible with the test as it is so it'll give the
same result.

> Yes, but please do not take any comfort from that.  I would have very
> little comfort in the accuracy of the the choice of cross-compile
> default in our autoconf tests.  I say this because while this may be the
> exception, the typical pattern was to just copy the last similar test,
> and modify it.  It can't be easily shown that whoever wrote this test
> considered this carefully.  (The same often applied to the choice of
> compile/run).

The statfs.f_fsid check will fail if there's none irrespective of
executing it.

> Adding the the confusion, I added
> 2a4eaa3241fc4ccb79359ea4e4d511754a84d46b only recently, with
> execute=True, in order to make the FreeBSD build match the waf build.  

Ouch!
But you don't need to execute that, the compiler will bail out with an
error ‘struct statfs’ has no member named ‘f_iosize' on linux.
There are many other tests that can probably be modified to work with
Execute=false, i didn't do a complete audit, i've just "fixed" the ones
that weren't responsive to the answers cache.
Regards.



More information about the samba-technical mailing list