lkml.org 
[lkml]   [2000]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    "Peter Samuelson" <peter@cadcamlab.org> wrote :
    > [Dana Lacoste]
    > > 2 - programs that need to compile against the current kernel MUST
    > > be able to do so in a quasi-predictable manner.

    > (2) is bogus. NO program needs to compile against the current kernel
    > headers. The only things that need to compile against the current
    > kernel headers are kernel modules and perhaps libc itself. As I put it
    > a few days ago--

    > http://marc.theaimsgroup.com/?l=linux-kernel&m=97658613604208&w=2

    > So for your external modules, let me suggest the lovely
    > /lib/modules/{version}/build/include/. Recent-ish modutils required.

    ok, i'll rephrase my request :)

    For sake of argument (i.e. this might not be true, but pretend it is :)

    - I write an external/third party kernel module
    - For various reasons, I must have this kernel module installed to boot
    (i can't compile without my module running)
    - I need to upgrade kernels to a new version, one where there are
    not-insignificant changes in the kernel headers.
    - I distribute this module online, and thousands of people use this module
    with various platform and distribution combinations.

    How can I know where the 'correct' Linux kernel headers are in such
    a way that is as transparent as possible to the user doing the compiling?

    Potential answers that have come up so far :
    1 - /lib/modules/* directories that involve `uname -r`
    This won't work because i might not be compiling for the `uname -r` kernel
    2 - /lib/modules/<version>/build/include/ :
    we could recommend that all kernel headers for all versions be put in
    the directory with the modules as listed above. someone doesn't like
    the idea of symlinks (dangling symlinks ARE bad :) and someone else
    pointed
    out that his root partition is only 30MB. therefore this idea has flaws
    too.
    3 - the script (Config.make, etc) approach : several people recommended one
    kind or another of script that could be run prior to compilation that
    could set all the relevant variables, including one that would point to
    where the kernel headers are, and one that would have the 'correct'
    compile flags, etc.
    4 - a link in the /usr/include directory tree that points to the kernel
    headers,
    so that /usr/include/linux would have the glibc-compiled headers, and this
    other directory would have the current kernel's headers : this doesn't
    really support cross-compiling.

    #1 and #2 and #4 all seem to be limiting somehow. I think the biggest problem
    so far has been that many developers don't recognize just how varied the linux
    development universe is! For me personally, it's nothing to cross-compile for
    other hardware platforms, and any solution that doesn't take that possibility
    into account is just being silly :)

    Can we get a #3 going? I think it could really help both the cross-compile
    people and those who just want to make sure their modules are compiling in
    the 'correct' environment. It also allows for things like 'kgcc vs. gcc' to
    be 'properly' resolved by the distribution-creator as it should be, instead of
    linux-kernel or the 3rd party module mailing lists.

    So? What do you think?

    --
    Dana Lacoste
    Linux Developer
    Peregrine Systems


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:52    [W:0.024 / U:91.612 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site