Re: df is never built while cross-compiling for a linux target
Mike Frysinger [EMAIL PROTECTED] 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. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: df is never built while cross-compiling for a linux target
Hello Mike, all, * Mike Frysinger writes: 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 This idea has some appeal to it. Not sure whether another optional argument to AC_RUN_IFELSE for explanation would be the best. But for a start you can get a good idea of runtime issues using this command to show the cross-compile settings of macros: autoconf '--trace=AC_TRY_RUN:$f:$l:$4' '--trace=AC_RUN_IFELSE:$f:$l:$4' Hope that helps. Please Cc: me on replies. Cheers, Ralf ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: YYYYMMDD HHMMSS [TZ] ?
[EMAIL PROTECTED] (Karl Berry) writes: date -d can understand MMDD HHMM [TZ]. Would MMDD HHMMSS [TZ] be possible? Hmm, does the first form actually work for you? It doesn't for me: $ date -d '20070507 1138 -0700' date: invalid date `20070507 1138 -0700' I'm not sure exactly what the issues are, since the code is pretty funky at this point. (I guess first I'd like to know what works for you now :-). ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: YYYYMMDD HHMMSS [TZ] ?
date -d can understand MMDD HHMM [TZ]. Would MMDD HHMMSS [TZ] be possible? Hmm, does the first form actually work for you? You're right, with the TZ it doesn't. Sorry for my confusion. date -d '20070507 1138' is ok, date -d '20070507 1138 -0700' is invalid. Supporting YYYMMDD HHMMSS (without the TZ) would be useful too, if the TZ causes extra complications (easy to imagine). since the code is pretty funky at this point. I think it has been since day 1 :). But date -d is still such a great thing ... thanks, k ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: YYYYMMDD HHMMSS [TZ] ?
[EMAIL PROTECTED] (Karl Berry) writes: date -d can understand MMDD HHMM [TZ]. Would MMDD HHMMSS [TZ] be possible? Hmm, does the first form actually work for you? You're right, with the TZ it doesn't. Sorry for my confusion. date -d '20070507 1138' is ok, date -d '20070507 1138 -0700' is invalid. Supporting YYYMMDD HHMMSS (without the TZ) would be useful too, It already supports -MM-DD HH:MM:SS (also with TZ). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
