bug-coreutils
[Top][All Lists]
Advanced

[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 07:13:44 +0200

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?

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]