Help - 'make' errors dealing with Kernel Source - all my kernel source code, old and new

Fri Jun 23 22:14:48 UTC 2006

I was up last night and missed the post.  I have noticed the Ubuntu user list moves at a much quicker rate than what I am used to on other mailing lists such as Debian and its separate lists.    I had to turn on threading to make sure I did not miss anything.

Erik Christiansen wrote:
> On Thu, Jun 22, 2006 at 12:10:50PM -0700, Adam D wrote:

<snip>

>> ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
>> ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
>> #include "..." search starts here:
>> #include <...> search starts here:
>>  /usr/local/include
>>  /usr/lib/gcc/x86_64-linux-gnu/4.0.3/include
>>  /usr/include 
>> End of search list.
> 
> shows that the #include <errno.h> in mcconf.c will be the first found in
> /usr/local/include , /usr/lib/gcc/x86_64-linux-gnu/4.0.3/include , or
> /usr/include, for the simple "gcc -v scripts/kconfig/mconf.c" case. 
> 
> When invoked from a makefile, gcc will only look in other paths if the
> makefile has -Isome_path options in CFLAGS assignments. (-iquoteDIR or
> -idirafter are possible, but less likely.) What is shown by:
> 
> grep -ne '-I' Makefile

The Result is:

 # grep -ne '-I' Makefile
302:LINUXINCLUDE    := -Iinclude \
303:                   $(if $(KBUILD_SRC),-Iinclude2 -I$(srctree)/include) \
1219:                echo "-I __initdata,__exitdata,__acquires,__releases  \
1220:                      -I EXPORT_SYMBOL,EXPORT_SYMBOL_GPL              \
1233:                echo "-I __initdata,__exitdata,__acquires,__releases  \
1234:                      -I EXPORT_SYMBOL,EXPORT_SYMBOL_GPL              \

>>> $ egrep -nr mcconf.o scripts       # To find the makefile dependency entry.
>> I did this on the command line and it just returned the prompt without any 
>> output to the screen.
> 
> Rats, that means the makefile is rule-based, and lacks an explicit
> dependency list. (That's easier for the kernel authors, but robs us of
> the easy option for finding the best place to insert the -v, for
> diagnosing mcconf.c explicitly.) However, we've worked around that.
> 
>> Now since this is a vanilla kernel I have never had kernel headers.  The only 
>> time I had kernel headers with the kernel source was installed from the 
>> distributer.  
> 
> Oh - Oh! Now he mentions it. :-)

Hehehe.. oups, sorry ;)  

Not all is lost.. I have been picking up new things to help any future diagnosing kernel issues and is more to add to the knowledge bank.  This is all very informative and very helpful and useful.  Been keeping these emails in a directory so I can come back to them for future help..  

> 
> Googling a "Linux kernel Howto", I didn't find any mention of explicit
> kernel headers in either of 2 Howtos. However, given that your current
> set-up is borked, it is likely to be quicker to just download a fresh
> source package, .e.g. following
> http://www.digitalhermit.com/linux/Kernel-Build-HOWTO.html
> and follow the steps.
> 
> If you would like to take a last fling with the current setup, you could
> try adding -I/usr/include/linux/ to the "CFLAGS := ... " line in the
> appropriate makefile. So long as you have /usr/include/linux/errno.h,
> then the errors should go away. To confirm we're in the right file:
> 
> find /usr/src/linux -name '[Mm]akefile' -exec grep oldconfig {} \;

It just issued a blank prompt.

> 
> should show you which makefile is used to "make oldconfig" It is most
> likely just the one we've been lookng in.
> 
>>> Now, before we go further, there's not an earlier error is there, saying
>>> ------------------------------------------------------------------------
>>> something remotely like ".../.../errno.h: File not found" ??
>>> ------------------------------------------------------------
>>>
>> Unfortunly there is not.  The errors I had posted was the only outup to the 
>> term right after I did a make oldconfig
> 
> That is really odd, since finding any errno.h should remove the errors
> you have. You're staring down the barrel of being sufficiently
> incompatible with current kernel source, to give quite a load of grief.
> 
> There are times when discretion beats valour hands down. I'd seriously
> consider grabbing a new source download, and banging through the steps
> of the very latest kernel Howto. (If nothing else, it would provide a
> fresh perspective.)

Hmmm.  So could have something been corupted during the file transfer?  

<snip>

>> It does not look like it is there.  So, I am taking it that it is a config 
>> somewhere in my source?  
> 
> Flicking through the Configuration section of a Kernel Howto for the
> first time, I didn't see any reference to headers or include paths, so
> it's not easy to see misconfiguration as a likely cause. Unless you've
> found such a reference, I'd suggest that your symlink is possibly
> confusing the new kernel version, and it'd be best to remove it and any
> others in the area, and try the configuration and build steps again.

Now on the PPC I have used these years a link in /usr/include/linux to point to /usr/src/linux/include/linux,  (for all my vanilla kernels) should I not have anything there?  I still have the orriginal /usr/include/linux directory from the install and can move that back.  I had thought the /usr/include/linux (the directory included with a install of a new running system) only worked with distribution packaged source, header files, no?  

> The distribution is designed to work with a standard (unmodified)
> environment, so that's the best base from which to tackle the new
> kernel. If it then gives trouble, remote diagnosis will be less
> difficult. (Not to mention local diagnosis. ;-)

Reading the README in the kernel source I found this:

INSTALLING the kernel:

 - If you install the full sources, put the kernel tarball in a
   directory where you have permissions (eg. your home directory) and
   unpack it:

                gzip -cd linux-2.6.XX.tar.gz | tar xvf -

   or
                bzip2 -dc linux-2.6.XX.tar.bz2 | tar xvf -

   Replace "XX" with the version number of the latest kernel.

   Do NOT use the /usr/src/linux area! This area has a (usually
   incomplete) set of kernel headers that are used by the library header
   files.  They should match the library, and not get messed up by
   whatever the kernel-du-jour happens to be.

Ummm That is what I have done.  Ok.. now I really feel low (missing this instruction) and back as a beginner in compiling kernel source. LOL

Now reading further I see this:

BUILD directory for the kernel:

   When compiling the kernel all output files will per default be
   stored together with the kernel source code.
   Using the option "make O=output/dir" allow you to specify an alternate
   place for the output files (including .config).
   Example:
     kernel source code:        /usr/src/linux-2.6.N
     build directory:           /home/name/build/kernel

   To configure and build the kernel use:
   cd /usr/src/linux-2.6.N
   make O=/home/name/build/kernel menuconfig
   make O=/home/name/build/kernel
   sudo make O=/home/name/build/kernel modules_install install

   Please note: If the 'O=output/dir' option is used then it must be
   used for all invocations of make.

I have been keeping all my kernel source in /usr/src with the appropriate 2.6.x.x and having a link pointing to the current one in use and call that linux.  Is that now not done any more?  The last instruction (INSTALLING the kernel:)  said I should not put it in the /usr/src/linux or was it meaning right in the full path of /usr/src/linux (which /usr/src/linux is really a link pointing to the current kernel source).  I have noticed that even sudo make, the admin can't really compile the kernal.  I am wondering now that I have been doing things rather odd (not the proper way or just have not kept up with what is current) all this time?  Well it is good to get it all cleaned up now. :)

-Adam