Olivier Dion schreef op za 09-04-2022 om 10:40 [-0400]:
> On Sat, 09 Apr 2022, Maxime Devos <maximedevos@telenet.be> wrote:
> > Maxime Devos schreef op za 09-04-2022 om 11:11 [+0200]:
> > (define (excluded-input? input)
> >           (directory-exists? (string-append store-item
> >           "/include/linux"))))))
> [...]
> I assume that for glibc that's okay because the toolchain was built with
> '--with-native-system-header-dir=DIRNAME' or something like that.

Some remarks:

  * Let 'foo' be a program depending on the C library 'bar' whose
    headers include some headers from 'linux-libre-headers' and
    'glibc'.

  * Almost every C program includes some headers of glibc anyway,
    so to compile the C program 'foo', you would need to have a glibc
    in the environment anyway, so absoluting the references to glibc
    headers doesn't bring much here.

  * Even then, as you say, the toolchain is compiled with something
    like that.

> I'm not sure if that's okay.  What if the package require kernel's
> headers?  Would this works if testing a custom kernel?

  * Looking at the existence of $GUIX_ENVIRONMENT/include/linux when
    doing "guix shell -D hello --pure", it looks like (a slightly
    old version of) linux-libre-headers is included by default in the
    build environment, so the package will have some kernel headers
    automatically.

  * Suppose that 'linux-libre-headers' was not excluded.
    Suppose that 'bar' depends on 'linux-libre-headers', and hence some
    inclusions were absolutised.  Now suppose that 'foo' requires a
    _newer_ linux-libre-headers, say linux-libre-headers@5.15 to
    utilise some fancy new thing in Linux.

    Suppose the source code is something like:

    foo.c:
    #include <bar.h>
    #include <linux/stuff.h> --> absolutised to </...new-linux.../linux/stuff.h>

    bar.h:
    [standard include guard]
    #include <linux/stuff.h> ---> absolutised to </...old-linux.../linux/stuff.h>
    [standard include guard]

    linux/stuff.h
    [standard include guard]
    [stuff depending on the linux-libre-headers version]
    [standard include guard]

    Then, what would happen when 'foo.c', is that at first,
    the C compiler loads <bar.h>.  It sees that old-linux/stuff.h
    and loads it, including the include guard.  The next thing it
    sees is #include <linux/stuff.h>.  But then the compiler
    (mis)remembers, due to the include guard, that it included this
    header already, so it will not include the _new_ <linux/stuff.h>

    As such, foo.c would end up with the _old_ <linux/stuff.h>, even though
    it needed the new stuff (new structs or such).  By not absolutising the
    <linux/...>, the compiler will just look for <linux/...> in C_INCLUDE_PATH,
    and find the linux-libre-headers from lttng-ust's inputs.

    So I'm a bit hesitant to including linux-libre-headers.

Greetings,
Maxime.