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

[Erik Christiansen]

On Fri, Jun 23, 2006 at 03:14:48PM -0700, Adam D wrote:
...
> Erik Christiansen wrote:
...
> > 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              \

OK, in that lot, only line 303 shows up include paths: -Iinclude2 and
-I$(srctree)/include, but that's moot now.

...

> > 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.

That would have to work, if /usr/src/linux was the  directory in which
you had been running:

make oldconfig

because the makefile would complain if it lacked the "oldconfig" target.
So the symlink setup is not looking good. ("Incomplete kernel headers",
etc.)

...

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

Either gzip or bzip2 would warn in that case, if my experience is any
indication.

...

> > 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

<Rub_salt_in_wound>
Even (or especially) after having built several versions of gnu
toolchains for cross compiling to each of several different target
microprocessors, I take the trouble to check for any new gotcha in
README and INSTALL, before banging out the old build steps.

It pays off, because it's more fun to give advice than to receive it. ;-)
</Rub_salt_in_wound>

Mind you, it was only after the gcc build convention changed, a good
while back, that I developed the habit.

Incidentally, building the kernel in a user directory doesn't appeal to
me that much. My practice is to change /usr/local/src to my ownership,
copy downloads there, unzip & build. That avoids having system stuff
lurking in a user directory.

> 
> 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. :)

Glancing at the above, they seem to be following the good practice of
having a separate source tree for each version. (N = 0,1,...)

Then, without any symlinks to muck it up, cd into the playpen, and build
there. My first instinct would be to:

mkdir /usr/local/src/linux-2.6.N_build

and use O=/usr/local/src/linux-2.6.N_build

This avoids the forbidden /usr/src/linux, and userland.

But then, my experience is with gnu toolchains, eCos, net-snmp, and other odds
& sods, not specifically the kernel. So, best of luck. :-)

Erik