Skip to content

Create a way for offline building #17

Closed
#52
Closed
Create a way for offline building#17
#52
Labels
• kbuildRelated to building the kernel, `make`, `Kbuild`, `Kconfig` options...

Description

@kloenk
kloenk
opened on Oct 4, 2020

Some build systems (like nix) do not allow network access while building, but then provide a download phase, where network access is allowed.
For this to work with cargo, we would have to create a cargo vendor dir, and call cargo with the flags, to not update the index and use the vendor dir.

Activity

  1. ojeda commented on Oct 4, 2020

    @ojeda
    ojeda
    on Oct 4, 2020
    Member

    Agreed! Offline building will be supported (it is one of the requirements).

    At the moment, you may try prefetching the dependencies in the download phase.

  2. kloenk commented on Oct 4, 2020

    @kloenk
    kloenk
    on Oct 4, 2020
    MemberAuthor

    I saw in the docs something about charge fetch. But for nix it would be best I can do it out of tree and link the folder in tree later.
    To download I woul like to just copy one Cargo.lock

  3. kloenk commented on Oct 5, 2020

    @kloenk
    kloenk
    on Oct 5, 2020
    MemberAuthor

    I will try to build it via nix next week. If that succeeds, I'm happy to close this issue.
    Currently I also fail with this error. Did someone get this kernel to build?

    elf.c: In function ‘read_symbols’:
elf.c:378:8: error: implicit declaration of function ‘gelf_getsymshndx’; did you mean ‘gelf_getsym’? [-Werror=implicit-function-declaration]
  378 |   if (!gelf_getsymshndx(symtab->data, shndx_data, i, &sym->sym,
      |        ^~~~~~~~~~~~~~~~
      |        gelf_getsym
elf.c:378:8: error: nested extern declaration of ‘gelf_getsymshndx’ [-Werror=nested-externs]

  4. kloenk commented on Oct 5, 2020

    @kloenk
    kloenk
    on Oct 5, 2020
    MemberAuthor

    I will try to build it via nix next week. If that succeeds, I'm happy to close this issue.
    Currently I also fail with this error. Did someone get this kernel to build?

    elf.c: In function ‘read_symbols’:
elf.c:378:8: error: implicit declaration of function ‘gelf_getsymshndx’; did you mean ‘gelf_getsym’? [-Werror=implicit-function-declaration]
  378 |   if (!gelf_getsymshndx(symtab->data, shndx_data, i, &sym->sym,
      |        ^~~~~~~~~~~~~~~~
      |        gelf_getsym
elf.c:378:8: error: nested extern declaration of ‘gelf_getsymshndx’ [-Werror=nested-externs]

    Seems like i had an to old version of some dependencies

  5. ojeda commented on Oct 5, 2020

    @ojeda
    ojeda
    on Oct 5, 2020
    Member

    I will try to build it via nix next week. If that succeeds, I'm happy to close this issue.

    If you have the time to try, it would be great! The issue may remain opened since building in general (and offline building in particular) is not yet set in stone.

    Currently I also fail with this error. Did someone get this kernel to build?

    The branch is intended to always be building and working (CI was just added to keep it that way, too). Of course, mistakes could happen.

  6. kloenk commented on Oct 8, 2020

    @kloenk
    kloenk
    on Oct 8, 2020
    MemberAuthor

    I'm currently seeing this warning, is ../include/config/auto.conf something introduced by this fork?

    linux-config> sed: can't read ../include/config/auto.conf: No such file or directory

    (sorry, it's my first time working on the kernel)

  7. ojeda commented on Oct 8, 2020

    @ojeda
    ojeda
    on Oct 8, 2020
    Member

    No, it is something that appears the first time when you haven't configured or built the kernel previously (so after a make mrproper too). If you are using a config file from somewhere else, potentially from older versions of the kernel, you can run make oldconfig && make prepare (it will ask for new options if the old config didn't know about them).

    (Don't worry about asking!)

  8. kloenk commented on Oct 9, 2020

    @kloenk
    kloenk
    on Oct 9, 2020
    MemberAuthor

    I'm currently seeing this warning, is ../include/config/auto.conf something introduced by this fork?

    linux-config> sed: can't read ../include/config/auto.conf: No such file or directory

    This line seems to be the problem if you build with O=$something

    linux/scripts/Makefile.lib

    Line 232 in f60edb2

    rustc_cfg_flags = $(shell sed -nE 's/^(CONFIG_[^=]+)=(y|m)$$/--cfg \1/p' $(srctree)/include/config/auto.conf | xargs)

  9. kloenk commented on Oct 9, 2020

    @kloenk
    kloenk
    on Oct 9, 2020
    MemberAuthor

    Not sure what I did, but I got it to die with this error:

    scripts/kconfig/conf  --oldconfig Kconfig
make[1]: scripts/kconfig/conf: Argument list too long
make[1]: *** [scripts/kconfig/Makefile:71: oldconfig] Error 127
make: *** [Makefile:627: oldconfig] Error 2

  10. kloenk commented on Oct 9, 2020

    @kloenk
    kloenk
    on Oct 9, 2020
    MemberAuthor

    What about changing from --cfg to std::env!()? This would maybe produce more binary code, but it also would enable us to get values inside of rust.
    Furthermore, auto.conf seems to be configurable where it will be placed. And it may get so big, that it exceeds the max argument length of a Linux shell.

    @ojeda What do you think about this? should I open an Issue/PR for this?

  11. ojeda commented on Oct 10, 2020

    @ojeda
    ojeda
    on Oct 10, 2020
    Member

    This line seems to be the problem if you build with O=$something

    linux/scripts/Makefile.lib

    Line 232 in f60edb2

    rustc_cfg_flags = $(shell sed -nE 's/^(CONFIG_[^=]+)=(y|m)$$/--cfg \1/p' $(srctree)/include/config/auto.conf | xargs)

    Good catch, we need to avoid reading the file when not needed.

    What about changing from --cfg to std::env!()? This would maybe produce more binary code, but it also would enable us to get values inside of rust.

    Do you mean avoiding conditional compilation altogether?

    Furthermore, auto.conf seems to be configurable where it will be placed. And it may get so big, that it exceeds the max argument length of a Linux shell.

    Does rustc support other ways of passing cfg variables? If not, the best would be to have that support added (even if we didn't hit issues with length etc., it is not nice to see pages of arguments when building verbosely).

    @ojeda What do you think about this? should I open an Issue/PR for this?

    Definitely! Please open the issue.

  12. kloenk commented on Oct 10, 2020

    @kloenk
    kloenk
    on Oct 10, 2020
    MemberAuthor

    What about changing from --cfg to std::env!()? This would maybe produce more binary code, but it also would enable us to get values inside of rust.

    Do you mean avoiding conditional compilation altogether?

    Yes, that was my idea. We maybe could create special cases, like some debug values or so, but I think the should be opt-in

    Furthermore, auto.conf seems to be configurable where it will be placed. And it may get so big, that it exceeds the max argument length of a Linux shell.

    Does rustc support other ways of passing cfg variables? If not, the best would be to have that support added (even if we didn't hit issues with length etc., it is not nice to see pages of arguments when building verbosely).

    I'm currently trying to figure this out and ask in the rust zulipchat.

    @ojeda What do you think about this? should I open an Issue/PR for this?

    Definitely! Please open the issue.

    Opened as #22

  13. ojeda commented on Oct 10, 2020

    @ojeda
    ojeda
    on Oct 10, 2020
    Member

    Yes, that was my idea. We maybe could create special cases, like some debug values or so, but I think the should be opt-in

    No, conditional compilation must work -- nobody will settle on something so fundamental (myself included!). It is not just about bloat or performance (which are both a big no-no), but also about complexity (we'd need to define what subset goes in), divergence (developers expect all CONFIG_* options to be available), etc.

    I'm currently trying to figure this out and ask in the rust zulipchat.

    Opened as #22

    Thanks a lot x2!

  14. kloenk
    added
    • kbuildRelated to building the kernel, `make`, `Kbuild`, `Kconfig` options...
    on Oct 10, 2020

  15. kloenk commented on Oct 15, 2020

    @kloenk
    kloenk
    on Oct 15, 2020
    MemberAuthor

    Thus std aware cargo is the biggest blocker for me at the moment. Is it reasonable to disable it, until it is stable in cargo?

  16. 67 remaining items

  17. metaspace
    added 2 commits that reference this issue on Nov 12, 2025

    perf test: Don't leak workload gopipe in PERF_RECORD_*

    28281ff

    hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()

    4891bf2
  18. ojeda
    added a commit that references this issue on Dec 4, 2025

    Merge patch series "can: netlink: add CAN XL support"

    113aa91
  19. BennoLossin
    added a commit that references this issue on Jan 13, 2026

    ecryptfs: Release lower parent dentry after creating dir

    5c56afd
  20. ojeda
    added a commit that references this issue on Feb 22, 2026

    perf cs-etm: Fix decoding for sparse CPU maps

    a70493e
  21. BennoLossin
    added 4 commits that reference this issue on Mar 19, 2026

    perf cs-etm: Fix decoding for sparse CPU maps

    4f30f0b

    mptcp: pm: in-kernel: always set ID as avail when rm endp

    4d480ef

    mptcp: pm: in-kernel: always set ID as avail when rm endp

    1b3ff4d

    mptcp: pm: in-kernel: always set ID as avail when rm endp

    7c1d221
  22. ojeda
    added 2 commits that reference this issue on Apr 18, 2026

    net/sched: cls_fw: fix NULL dereference of "old" filters before change()

    65782b2

    perf annotate: Use jump__delete when freeing LoongArch jumps

    a355eef
  23. Darksonn
    added a commit that references this issue on Jun 16, 2026

    mm/swap: add cond_resched() in swap_reclaim_full_clusters to prevent …

    66366d2
  24. ojeda
    added a commit that references this issue on Sep 11, 2026

    smb: client: reject userspace cifs.idmap descriptions

    d9d7eeb
  25. ojeda
    added a commit that references this issue on Sep 19, 2026

    tcp: Don't call skb_clone_and_charge_r() for close()d listener in tcp…

    8e759cd
  26. ojeda
    added a commit that references this issue on Sep 27, 2026

    fs: don't create the private nullfs mount under namespace_sem

    5179241
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    • kbuildRelated to building the kernel, `make`, `Kbuild`, `Kconfig` options...

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions