[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: df is never built while cross-compiling for a linux target
From: |
Jim Meyering |
Subject: |
Re: df is never built while cross-compiling for a linux target |
Date: |
Mon, 07 May 2007 08:44:17 +0200 |
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.
- df is never built while cross-compiling for a linux target, Mike Frysinger, 2007/05/06
- Re: df is never built while cross-compiling for a linux target, Jim Meyering, 2007/05/06
- Re: df is never built while cross-compiling for a linux target, Mike Frysinger, 2007/05/06
- Re: df is never built while cross-compiling for a linux target, Jim Meyering, 2007/05/06
- Re: df is never built while cross-compiling for a linux target, Mike Frysinger, 2007/05/06
- Re: df is never built while cross-compiling for a linux target, Jim Meyering, 2007/05/07
- Re: df is never built while cross-compiling for a linux target, Mike Frysinger, 2007/05/07
- Re: df is never built while cross-compiling for a linux target,
Jim Meyering <=
- Re: df is never built while cross-compiling for a linux target, Ralf Wildenhues, 2007/05/07