On Monday 07 May 2007, Jim Meyering wrote: > Mike Frysinger <[EMAIL PROTECTED]> wrote: > > On Sunday 06 May 2007, Jim Meyering wrote: > >> Mike Frysinger <[EMAIL PROTECTED]> wrote: > >> > is there a case that may not pass properly for linux ? if not, we > >> > could have the cross-compile fallback of AC_TRY_RUN() check $host for > >> > *-linux* and have it assume > >> > >> I see that my desktop defines STAT_STATFS2_BSIZE. If you can confirm > >> that (or any other approach) works for some limited set of Linux systems > >> (with a specific range of version numbers for both glibc and linux), > >> then there's a chance. > >> > >> Given linux, you might be able to replace that AC_TRY_RUN test with > >> a similar compile+link-only one. Assuming Linux and specific libc > >> versions, you can probably assume there is a prototype for statfs2, > >> and that should be enough to detect whether statfs takes 2 arguments. > >> Or maybe even don't worry about 2-arg vs N-arg, in the likely event that > >> glibc has never provided that function with any other number of > >> arguments. > > > > statfs has existed in it's current form since it was first added (based > > on looking at glibc symbol versions) ... ive tested glibc-2.2.5 and > > glibc-2.5 and the test you're referring to passes on both > > > >> I think you know, but I have to say it: > >> There's a good reason for not doing things that way: it's not > >> maintainable. There are enough 'gotcha's and and variation between > >> versions that I'd be very hesitant about using such short-cuts. In > >> general, it's not worthwhile to try to short-circuit the run-time tests. > >> Doing this sort of thing is sort of like going back to pre-autoconf > >> days, with things like #if defined __hpux__ || defined __sun__ in your C > >> code. > > > > sure, it's an ugly slippery slope ... the current situation though > > requires digging through autotools source code to try and find the right > > variables you have to force ... for the general user, i think this is > > usually above their heads :/ > > 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 ;) > 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 ? -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
