Re: df is never built while cross-compiling for a linux target

[Jim Meyering]

Mike Frysinger <address@hidden> wrote:
>> Of course it's over the head of the "general user" ;-)
>> How many "general users" do you know that do cross compiles?
>
> i guess you dont subscribe to the arm mailing lists ;)

Oh ;)

>> What do you think about documenting the procedure used to determine the
>> list of variables to force, along with that to find values appropriate
>> for the target?  If that's currently too hard, it might makes sense to
>> change the form (not function) of the tests to make it easier to identify
>> (perhaps even automatically) those variables.
>
> the issue does go beyond this specific fs test as there are a bunch of common
> vars that come from gnulib that do not get set properly in cross-compiling
> (like the silly GNU malloc(0) / rpl_malloc test) ... perhaps start with
> gnulib and have some common m4 file spit out a notice for people when they're
> doing cross-compiling to visit some document for further info ... not sure
> what sort of mechanism would exist though for automatically extracting and
> documenting though ... i can dabble in m4, but it's certainly not a strong
> point of mine
>
> speaking specifically to the statfs test here, does it actually need to be an
> AC_TRY_RUN ?  are there known cases it's trying to account for where the code
> compiles but the host libc/kernel handles it improperly ?

I don't think so, and I see no evidence of that in the deltas from the
birth of coreutils/m4/fsusage.m4 (extracted from fileutils/configure.in)
to its move to gnulib.  But that doesn't say much, since most of the
development happened before then.

However, one risk of using a compile-only check is that with a libc-provided
stub function, it can pass mistakenly.  And there are three more tests
for statfs variants after the one Linux uses.

But maybe my wariness of stubs is a red herring: if that is the case,
then removing the run-test might work just fine.

Here's an idea:
  perform that particular test two ways:
    once using the existing run-tests,
    once using only compile/link tests.
  If the results differ (for non-cross-compile), then abort the configure
  run with a request to report the anomaly, and with instructions
  telling how to rerun ./configure while skipping this comparison.
  [there's an example of this interaction in ftruncate.m4]

If that survives gnulib testing and a coreutils release,
I'll be happy to remove the run-test.

Or, more conservatively (but less-maintainable, due to duplication):
  once we're confident that the compile/link-only test is reliable,
  run it only when cross-compiling.