[OpenAFS] Problem building openafs on kernel 184.108.40.206-34-default
Thu, 04 Jan 2007 12:05:55 -0800
Marcus Watts <email@example.com> writes:
> 2.6 uses kbuild, not cc. The logic for this is in
> which is defined in
> It should save standard error, so, yes, there is *some* stuff.
> The vanilla openafs logic here doesn't explicitly save the command or
> the test fragments that failed. That means it's not always easy to
> figure out exactly what broke. I came up with this patch after I had a
> build break and had to figure out why. Turns out user mode linux is
> particularly keen on weird -I logic, like relative path names, and the
> error message from the compiler just isn't sufficient. Compare that to
> the situation where a regular compile probe fails - there you
> automatically get the failing program, the compile command that failed,
> etc -- these are standard features of the built-in configure logic and
> supplies all the information necessary to reproduce the problem
> Since vanilla openafs configure doesn't try doing a vanilla kernel build
> before it tests for features, it doesn't actually know if any kernel
> build can succeed. That's why the rlim test is confusing - this isn't
> the 1st kernel test that fails. It's the first one that fails with no
> workaround. Talk about obscure.
> Clearly, this is a common problem. Do we really not want to make it
> easier for people who haven't fixed this dozens of times to recognize &
> solve the problem?
I've applied your patch to head after reviewing it, and will pull it up
for 2.5 and 2.4 when I get back from lunch.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>