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

[Mike Frysinger]

On Monday 07 May 2007, Jim Meyering wrote:
> Mike Frysinger <address@hidden> wrote:
> > On Sunday 06 May 2007, Jim Meyering wrote:
> >> Mike Frysinger <address@hidden> 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.