Help - 'make' errors dealing with Kernel Source - all my kernel source code, old and new
Erik Christiansen
erik at dd.nec.com.au
Fri Jun 23 04:06:04 UTC 2006
On Thu, Jun 22, 2006 at 12:10:50PM -0700, Adam D wrote:
> Erik Christiansen wrote:
> <snip>
> >
> > Please run gcc with the additional option: -v
> > You can do this globally by adding it to the "CFLAGS=..." line that
> > should be in the early part of the relevant makefile. (The kernel's big,
> > nd I fear that it might use recursive make. So:
> >
> I did a grep -n of CFLAGS
>
> ../src/linux # grep -n CFLAGS Makefile
> 188:HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer
> 293:CFLAGS_MODULE = $(MODFLAGS)
> 296:CFLAGS_KERNEL =
> 308:CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
> 317: ARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC \
> 322:export CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
> 467:CFLAGS += -Os
> 469:CFLAGS += -O2
> 473:CFLAGS += -fno-omit-frame-pointer $(call
> cc-option,-fno-optimize-sibling-calls,)
> 475:CFLAGS += -fomit-frame-pointer
> 479:CFLAGS += -fasynchronous-unwind-tables
> 483:CFLAGS += -g
> 493:CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
> 496:CFLAGS += $(call cc-option,-Wno-pointer-sign,)
>
> To which CFLAGS do I add the -v to in the Makefile in /usr/src/linux directory?
The good news is that the command you ran in the terminal provides part
of the needed information, since we used -v there. Your output:
> 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
> > $ 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. :-)
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 {} \;
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.)
> > Because EINTR should not be undefined if any flavour of errno.h is
> > actually included when gcc compiles mconf.c. This means that there
> > should have been an earlier error message in the compiler output. (Maybe
> > a thousand lines earlier, if you're building the whole kernel? Search for
> > errno.h from the top of our "script" output.)
> >
> >> So, it does look like the new 2.6.17.1 code has a bit minor issue with me.
> >
> > Nah, if that humungous kernel mostly builds, just complaining about one
> > measly header file, then it likes you, and is only teasing. ;-)
> >
> >> I do hope that helps...and thank you very much :).
> >
> > No worries. :-)
> >
> > A last hint. The start of output from
> > "gcc -v scripts/kconfig/mconf.c ..." should roughly be along the lines of:
> Is that 'gcc -v scripts/kconfig/mconf.c' ran in the term? I did and it gives
> me the version of gcc and then the same errors at the end.
>
> >
> > ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
> > ignoring nonexistent directory "/usr/include/i486-linux-gnu"
> > #include "..." search starts here:
> > #include <...> search starts here:
> > /usr/local/include
> > /usr/lib/gcc/i486-linux-gnu/4.0.2/include
> > /usr/include
> > End of search list.
> >
> > If any errno.h was really used to compile mcconf.c, it will be in a
> > path in the <...> part of the list.
>
> ../src/linux # gcc -v scripts/kconfig/mconf.c
> Using built-in specs.
> Target: x86_64-linux-gnu
> Configured with: ../src/configure -v
> --enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
> --enable-shared --with-system-zlib --libexecdir=/usr/lib
> --without-included-gettext --enable-threads=posix --enable-nls
> --program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
> --enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
> --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
> --disable-werror --enable-checking=release x86_64-linux-gnu
> Thread model: posix
> gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
> /usr/lib/gcc/x86_64-linux-gnu/4.0.3/cc1 -quiet -v scripts/kconfig/mconf.c
> -quiet -dumpbase mconf.c -mtune=k8 -auxbase mconf -version -o /tmp/ccsT7Cvx.s
> 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.
> GNU C version 4.0.3 (Ubuntu 4.0.3-1ubuntu5) (x86_64-linux-gnu)
> compiled by GNU C version 4.0.3 (Ubuntu 4.0.3-1ubuntu5).
> GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128106
> scripts/kconfig/mconf.c: In function 'exec_conf':
> scripts/kconfig/mconf.c:488: error: 'EINTR' undeclared (first use in this
> function)
> scripts/kconfig/mconf.c:488: error: (Each undeclared identifier is reported
> only once
> scripts/kconfig/mconf.c:488: error: for each function it appears in.)
> scripts/kconfig/mconf.c:488: error: 'EAGAIN' undeclared (first use in this
> function)
>
>
> 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.
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. ;-)
Erik
More information about the ubuntu-users
mailing list