2.6.35.10-74 compilation (and build) problems

[Mr Dash Four]

>> See the "Fedora Wiki" ( :-D ) for building the kernel - the target arch 
>> needs to be added as a comment on the first line of that .config file 
>> (that is particularly important if I do cross-compilation of the kernel 
>> - I add "# i386" for i686 targets for example). If that is not present 
>> all hell breaks loose!
>>     
>
> I think we use it during the 'make nonint_oldconfig' stage, ala
>
> for i in $config_list
>   ARCH=`cat $i|head -1|sed 's/# //'`
>   cp $i .config
>   make ARCH=$ARCH nonint_oldconfig
>   cp .config configs/$i
>
> without the #$arch thing, we wouldn't know what arch to pass into the
> kernel Makefile system to get the right config options.
>   
When I start the "rpmbuild -bb" process (from where everything kicks on) 
I could specify a "--target=XX" parameter. Why can't the build system 
utilise that? A simple solution would be "echo <target_parameter_value> 
 > .target_arch", not to mention that this can also be stored in the 
environment as a variable. To add '# arch' every time I change the 
.config file is a bit, well, archaic, don't you think?

>>>> cp .config ~/rpmbuild/SOURCES/config-x86_64-generic
>>>>         
>
> Yeah that won't work (explained below)
>   
Would it work if I delete ALL .config files and leave the one I quoted 
above? If all .configs just 'stack-up', then by deleting everything else 
but what I actually configured should, in theory, do the trick, right?


>> What do they actually change - after I build and install the kernel and 
>> then check the corresponding .config file in the /boot 
>> partition/directory it is the same as the one I have copied as 
>> config-x86_64-generic, so, naturally, I assume that nothing has been 
>> modified/changed. Is that not the case?
>>     
>
> The way the config options work is basically a bunch of templates that
> override each other as they get stacked on top.  So
>
> config-generic is usually the base config that all arches start with
> config-$ARCH-generic is merged onto config-generic and overrides those
>     options
> config-$ARCH-$VARIANT is merged onto that with more overrides
>
> the result config blob is full of stuff that may or may not be relevant to
> the particular type of kernel we are building, therefore we use the
> for-loop (from earlier in the email), to filter out that cruft.  The magic
> is 'make ARCH=$ARCH nonint_oldconfig'  (think make oldconfig without the
> prompting).
>   
Riiiight! I get it now - a bit complicated, but at least I know what is 
happening! Thanks for that insight! My suggestion above stays though - 
would it work that way?

> The output files are kernel-$version-$arch.config.  If you want to copy
> .config files somewhere, it really should be the kernel-*.config files.
>   
I've noticed there are 2 files like that 
linux-<ver>-<arch>/configs/kernel-<ver>-<arch>.config and another file 
called kernel-debug-<ver>-<arch>.config. these files have the DRM_NOVEAU 
section of options missing from my .34 config file, but they are just a 
starting point and if I want to merge an older version (.34) with these 
by using oldconfig, that won't work - I already tried that as well.

> But I don't have the .spec file handy to know if those get repeatedly
> overwritten on a rpmbuild.
>   
Tomorrow when I have more time to play with this stuff I would be able 
to check it out.

> The way the kernel maintainers set the options is to modify the
> config-$pickone-generic  file with the option you care about to on/off.
>
> But as explained in other threads, we never supported custom configs so no
> one really designed a process to make it easy.
>   
So, if I use my customised .config file from the .34 version and call it 
config-x86_64-generic would that do the trick? Would I be able to get 
all the options merged in the final  configs/kernel-2.6.35.xx-xx.config 
file do you think?