Hi,
I'm trying to compile kernel 2.4.1 on RedHat 6.2 (zoot). After the make xconfig and make dep when I give make bzlilo I get the following error message
gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o
scripts/split-include
scripts/split-include.c
In file included from /usr/include/errno.h:36,
from scripts/split-include.c:26:
/usr/include/bits/errno.h:25: linux/errno.h: No such file or directory
make: *** [scripts/split-include] Error 1
What should I do?
Yours ,
Srinath.R
Make sure you have the following symlinks in your /usr/include
directory, assuming you're on an x86 machine:
asm -> /usr/src/linux/include/asm-i386/
linux -> /usr/src/linux/include/linux/
If you're using a different archetecture, check the
/usr/src/linux/include/ directory and make the link with that directory.
Steve
On 10 Mar 2001 20:16:34 +0530, Srinath Ravinathan wrote:
> Hi,
> I'm trying to compile kernel 2.4.1 on RedHat 6.2 (zoot). After the make xconfig and make dep when I give make bzlilo I get the following error message
>
> gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o
> scripts/split-include
> scripts/split-include.c
> In file included from /usr/include/errno.h:36,
> from scripts/split-include.c:26:
> /usr/include/bits/errno.h:25: linux/errno.h: No such file or directory
> make: *** [scripts/split-include] Error 1
>
> What should I do?
> Yours ,
> Srinath.R
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
In article <[email protected]>,
Stephen "M." Williams <[email protected]> wrote:
>Make sure you have the following symlinks in your /usr/include
>directory, assuming you're on an x86 machine:
>
>asm -> /usr/src/linux/include/asm-i386/
>linux -> /usr/src/linux/include/linux/
Note! You only have to have those symlinks on broken systems such
as Redhat.
Sane systems such as Debian have a copy of the kernel header files
that the C library was compiled against in /usr/include/{linux,asm}
instead of symlinks to the kernel source. Do not play the symlink
trick on those systems.
Before this turns into a flamewar: this has been discussed 20 or
so times before, and both Linus and the glibc developers agree
that you a distribution should do the latter. The headers you use
to compile userland binaries should be the same as the C library
was compiled against.
If you need to compile a standalone module use -I/usr/src/linux/include
Mike.
--
Go not unto the Usenet for advice, for you will be told both yea and nay (and
quite a few things that just have nothing at all to do with the question).
-- seen in a .sig somewhere
"Stephen M. Williams" wrote:
>
> Wow, I had no idea. I was following advice I received a long time ago
> from a mailing list. If I remove those symlinks how do I go about
> compiling the kernel without receiving the same errors as Srinath?
Note that he said distributions such as RedHat (pre 7.0 .. I think 7.0
does it correctly). On other distros those headers are/should be
included with the glibc devel stuff.
You could probably copy those dirs into place on the broken distros
without problems.
--
=====================================================================
Mohammad A. Haque http://www.haque.net/
[email protected]
"Alcohol and calculus don't mix. Project Lead
Don't drink and derive." --Unknown http://wm.themes.org/
[email protected]
=====================================================================
Wow, I had no idea. I was following advice I received a long time ago
from a mailing list. If I remove those symlinks how do I go about
compiling the kernel without receiving the same errors as Srinath?
Thanks for the correction,
Steve
On 10 Mar 2001 18:28:09 +0000, Miquel van Smoorenburg wrote:
> In article <[email protected]>,
> Stephen "M." Williams <[email protected]> wrote:
> >Make sure you have the following symlinks in your /usr/include
> >directory, assuming you're on an x86 machine:
> >
> >asm -> /usr/src/linux/include/asm-i386/
> >linux -> /usr/src/linux/include/linux/
>
> Note! You only have to have those symlinks on broken systems such
> as Redhat.
>
> Sane systems such as Debian have a copy of the kernel header files
> that the C library was compiled against in /usr/include/{linux,asm}
> instead of symlinks to the kernel source. Do not play the symlink
> trick on those systems.
>
> Before this turns into a flamewar: this has been discussed 20 or
> so times before, and both Linus and the glibc developers agree
> that you a distribution should do the latter. The headers you use
> to compile userland binaries should be the same as the C library
> was compiled against.
>
> If you need to compile a standalone module use -I/usr/src/linux/include
>
> Mike.
> --
> Go not unto the Usenet for advice, for you will be told both yea and nay (and
> quite a few things that just have nothing at all to do with the question).
> -- seen in a .sig somewhere
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Miquel van Smoorenburg wrote:
> Note! You only have to have those symlinks on broken systems such
> as Redhat.
This is silly, Red Hat works fine for a great many people.
He probably removed the original kernel-devel package,
which contained the links above, so they would have to
be remade.
> Sane systems such as Debian have a copy of the kernel header files
> that the C library was compiled against in /usr/include/{linux,asm}
I'm glad you admit that Red Hat is every bit as sane as
debian, since the current shipping version does indeed
have the sort of /usr/include/linux hierarchy you have just
described.
jjs
> >asm -> /usr/src/linux/include/asm-i386/
> >linux -> /usr/src/linux/include/linux/
>
> Note! You only have to have those symlinks on broken systems such
> as Redhat.
< 7.0.
On RH 6.x you should have a set of 2.2 header includes at /usr/src/linux as
required by the dependancies RPM uses. (kernel-headers package).
7.0 or higher keeps the glibc includes out of /usr/src
> He probably removed the original kernel-devel package,
> which contained the links above, so they would have to
> be remade.
Linking them to /usr/src and thus people linking them to current kernel sources
while basically harmless is indeed not the preferred approach. So he's right
that older RH should have put the headers for the kernel that match glibc into
/usr/include directly
According to Alan Cox:
> > Note! You only have to have those symlinks on broken systems such
> > as Redhat.
>
> < 7.0.
> 7.0 or higher keeps the glibc includes out of /usr/src
I stand corrected. Thanks.
Mike.
--
Go not unto the Usenet for advice, for you will be told both yea and nay (and
quite a few things that just have nothing at all to do with the question).
-- seen in a .sig somewhere
> >Make sure you have the following symlinks in your /usr/include
> >directory, assuming you're on an x86 machine:
> >
> >asm -> /usr/src/linux/include/asm-i386/
> >linux -> /usr/src/linux/include/linux/
>
> Note! You only have to have those symlinks on broken systems such
> as Redhat.
>
> Sane systems such as Debian have a copy of the kernel header files
> that the C library was compiled against in /usr/include/{linux,asm}
> instead of symlinks to the kernel source. Do not play the symlink
> trick on those systems.
>
> Before this turns into a flamewar: this has been discussed 20 or
> so times before, and both Linus and the glibc developers agree
> that you a distribution should do the latter. The headers you use
> to compile userland binaries should be the same as the C library
> was compiled against.
I've been following this advice for some time, but doing so tripped me up.
My system is RH 6.2, but with kernel 2.4 (and latest modutils etc). I
kept my kernel headers at 2.2.14, i.e. those supplied with the 6.2
kernel-headers RPM.
This breaks XFree 86 4, however, which checks the kernel version you are
*running* and then expects the headers for that kernel to be available. To
build X I had to move the symlink to point at some 2.4 headers so X could
find (IIRC) input.h, and others.
So what's at fault here? X for looking at the current kernel, me for not
telling X not to do that, or me again for not recompiling glibc and using
the new headers 'legally'?
Chris.