[BusyBox] loop.h requires dev_t be defined

[Erik Andersen]

On Fri Sep 01, 2000 at 10:10:45AM -0600, Erik Andersen wrote:
> On Tue Aug 29, 2000 at 04:39:17AM +0000, robotti at metconnect.com wrote:
> > 
> > I get this message from loop.h, the patch below
> > is for the latest cvs bb.
> > 
> > In file included from utility.c:62:
> > /usr/include/linux/loop.h:63: #error "Wrong dev_t in loop.h"
> > make: *** [utility.o] Error 1
> 
> 
> What version of libc, busybox, OS, etc.  I have heard scattered reports that
> this is a problem, but I have not been able to reproduce it.
> 

Ok, thanks to some help from Arne Bernin (who donated the temporary use of an
account on an afflicted machine), I now know what the problem is...

On your system, /usr/include/linux is a symlink to
/usr/src/linux/include/linux.  The kernel source is some nice new, current
2.2.x kernel.  Your libc was compiled against the kernel headers for 2.0.36.

To fix the problem, put back the kernel headers against which libc was compiled
(i.e. /usr/include/linux should not be a symlink, but should be a directory
with the kernel headers for some ancient kernel version).  The kernel headers
need not be the headers for the running kernel, they just need to be what your
C library was compiled with.

Quoting from /usr/share/doc/libc6/README.Debian.gz:


    Q1: Why does the Debian libc6-dev package create /usr/include/linux and
    /usr/include/asm directories containing header files from a specific
    kernel, instead of using the "established" convention of making those
    directories into symlinks pointing to the currently installed kernel?

    A1: Occasionally, changes in the kernel headers cause problems with the
    compilation of libc and of programs that use libc.  To ensure that users
    are not affected by these problems, we configure libc to use the headers
    from a kernel that is known to work with libc and the programs that depend
    on stable kernel headers.

    Q2: What if I want to compile a program that needs a feature from a later
    kernel than is used by libc?

    A2: In practice, most programs will not have this problem.  However,
    depending on the scope of the problem you have several options available:

    If the situation is one like "kernel driver development", where all use of
    the machine for development is expected to be against a different set of
    kernel headers than are supplied with the "stock" libc6-dev, rebuilding the
    glibc packages against that particular kernel will create a full set of
    libc6 packages that are "compliant" with the new kernel. All development
    done on machines with these packages installed will be done against the new
    kernel. To build libc6-dev against your particular kernel, export the
    environment variable ksource, set to the path to that particular kernel and
    build the package.

    If you want this new glibc package to stick against further upgrades,
    simply use dselect and place the packages on HOLD. This will keep them from
    being upgraded against your wishes.

    If there is just one particular program/package that needs different
    headers, and your kernel of choice is installed in the usual place, you can
    use the -I/usr/src/linux/include option on the gcc command line, when
    compiling that specific program.

 -Erik

--
Erik B. Andersen   email:  andersen at lineo.com
--This message was written using 73% post-consumer electrons--