18 Jan, 2020

1 commit

  • [ Upstream commit 8ffdc54b6f4cd718a45802e645bb853e3a46a078 ]

    Cross compiling the x86 kernel on a non-x86 build machine produces
    the following error when CONFIG_UNWINDER_ORC is enabled, regardless
    of whether libelf-dev is installed or not.

    dpkg-checkbuilddeps: error: Unmet build dependencies: libelf-dev
    dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
    dpkg-buildpackage: warning: (Use -d flag to override.)

    Since this is a build time dependency for a build tool, we need to
    depend on the native version of libelf-dev so add the appropriate
    annotation.

    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Sasha Levin

    Ard Biesheuvel
     

12 Jan, 2020

1 commit


25 Aug, 2019

3 commits


18 Jul, 2019

1 commit

  • While descending directories, Kbuild produces objects for modules,
    but do not link final *.ko files; it is done in the modpost.

    To keep track of modules, Kbuild creates a *.mod file in $(MODVERDIR)
    for every module it is building. Some post-processing steps read the
    necessary information from *.mod files. This avoids descending into
    directories again. This mechanism was introduced in 2003 or so.

    Later, commit 551559e13af1 ("kbuild: implement modules.order") added
    modules.order. So, we can simply read it out to know all the modules
    with directory paths. This is easier than parsing the first line of
    *.mod files.

    $(MODVERDIR) has a flat directory structure, that is, *.mod files
    are named only with base names. This is based on the assumption that
    the module name is unique across the tree. This assumption is really
    fragile.

    Stephen Rothwell reported a race condition caused by a module name
    conflict:

    https://lkml.org/lkml/2019/5/13/991

    In parallel building, two different threads could write to the same
    $(MODVERDIR)/*.mod simultaneously.

    Non-unique module names are the source of all kind of troubles, hence
    commit 3a48a91901c5 ("kbuild: check uniqueness of module names")
    introduced a new checker script.

    However, it is still fragile in the build system point of view because
    this race happens before scripts/modules-check.sh is invoked. If it
    happens again, the modpost will emit unclear error messages.

    To fix this issue completely, create *.mod with full directory path
    so that two threads never attempt to write to the same file.

    $(MODVERDIR) is no longer needed.

    Since modules with directory paths are listed in modules.order, Kbuild
    is still able to find *.mod files without additional descending.

    I also killed cmd_secanalysis; scripts/mod/sumversion.c computes MD4 hash
    for modules with MODULE_VERSION(). When CONFIG_DEBUG_SECTION_MISMATCH=y,
    it occurs not only in the modpost stage, but also during directory
    descending, where sumversion.c may parse stale *.mod files. It would emit
    'No such file or directory' warning when an object consisting a module is
    renamed, or when a single-obj module is turned into a multi-obj module or
    vice versa.

    Signed-off-by: Masahiro Yamada
    Acked-by: Nicolas Pitre

    Masahiro Yamada
     

17 Jul, 2019

1 commit

  • Debian-based distributions place libc header files in a machine
    specific directory (/usr/include/) instead of
    /usr/include/asm to support installation of the linux-libc-dev
    package from multiple architectures. Move headers installed by
    "make headers_install" accordingly using Debian's tuple from
    dpkg-architecture (stored in debian/arch).

    Signed-off-by: Cedric Hombourger
    Signed-off-by: Masahiro Yamada

    Cedric Hombourger
     

09 Jul, 2019

1 commit

  • header-test-y does not work with headers in sub-directories.

    For example, you may want to write a Makefile, like this:

    include/linux/Kbuild:

    header-test-y += mtd/nand.h

    This entry will create a wrapper include/linux/mtd/nand.hdrtest.c
    with the following content:

    #include "mtd/nand.h"

    To make this work, we need to add $(srctree)/include/linux to the
    header search path. It would be tedious to add ccflags-y.

    Instead, we could change the *.hdrtest.c rule to wrap:

    #include "nand.h"

    This works for in-tree build since #include "..." searches in the
    relative path from the header with this directive. For O=... build,
    we need to add $(srctree)/include/linux/mtd to the header search path,
    which will be even more tedious.

    After all, I thought it would be handier to compile headers directly
    without creating wrappers.

    I added a new build rule to compile %.h into %.h.s

    The target is %.h.s instead of %.h.o because it is slightly faster.
    Also, as for GCC, an empty assembly is smaller than an empty object.

    I wrote the build rule:

    $(CC) $(c_flags) -S -o $@ -x c /dev/null -include $<

    instead of:

    $(CC) $(c_flags) -S -o $@ -x c $<

    Both work fine with GCC, but the latter is bad for Clang.

    This comes down to the difference in the -Wunused-function policy.
    GCC does not warn about unused 'static inline' functions at all.
    Clang does not warn about the ones in included headers, but does
    about the ones in the source. So, we should handle headers as
    headers, not as source files.

    In fact, this has been hidden since commit abb2ea7dfd82 ("compiler,
    clang: suppress warning for unused static inline functions"), but we
    should not rely on that.

    Signed-off-by: Masahiro Yamada
    Acked-by: Jani Nikula
    Tested-by: Jani Nikula

    Masahiro Yamada
     

15 Jun, 2019

1 commit

  • It is absolutely fine to add extra sanity checks in package scripts,
    but it is not necessary to do so.

    This is already covered by the daily compile-testing (0day bot etc.)
    because headers_check is run as a part of the normal build process
    when CONFIG_HEADERS_CHECK=y.

    Replace it with the newly-added "make headers".

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

05 Jun, 2019

1 commit

  • The buildtar script might want to invoke a make, so tell the parent
    make to pass the jobserver token pipe to the subcommand by prefixing
    the command with a +.

    This addresses the issue seen here:

    /bin/sh ../scripts/package/buildtar tar-pkg
    make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule.

    See https://www.gnu.org/software/make/manual/html_node/Job-Slots.html
    for more information.

    Signed-off-by: Trevor Bourget
    Signed-off-by: Masahiro Yamada

    Trevor Bourget
     

21 May, 2019

1 commit


17 Mar, 2019

1 commit

  • * The man page for dpkg-source(1) notes:

    > -b, --build directory [format-specific-parameters]
    > Build a source package (--build since dpkg 1.17.14).
    >
    >
    > dpkg-source will build the source package with the first
    > format found in this ordered list: the format indicated
    > with the --format command line option, the format
    > indicated in debian/source/format, “1.0”. The fallback
    > to “1.0” is deprecated and will be removed at some point
    > in the future, you should always document the desired
    > source format in debian/source/format. See section
    > SOURCE PACKAGE FORMATS for an extensive description of
    > the various source package formats.

    Thus it would be more foolproof to explicitly use 1.0 (as we always
    did) than to rely on dpkg-source's defaults.

    * In a similar vein, debian/rules is not made executable by mkdebian,
    and dpkg-source warns about that but still silently fixes the file.
    Let's be explicit once again.

    Signed-off-by: Arseny Maslennikov
    Signed-off-by: Masahiro Yamada

    Arseny Maslennikov
     

14 Mar, 2019

4 commits

  • This will be a little more efficient since unset CONFIG options are
    stripped away from auto.conf, and we can hard-code the path to auto.conf
    since it is never overridden.

    include/config/kernel.release is generated before %pkg is run.
    So, it is guaranteed auto.conf is up-to-date.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • I think is_enabled() and if_enable_echo() in scripts/package/mkdebian
    are useful.

    builddeb also has many repetitive greps over the kernel config, so I
    borrowed the idea to clean it up.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • This might be a kind of bike-shed, but I personally prefer grep'able
    code.

    I often do 'git grep CONFIG_FOO' instead of 'git grep FOO' when I
    want to know where that CONFIG option is used.

    This makes code longer, but I hope this is acceptable level.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     
  • bison/flex is now needed always for building for kconfig. Some build
    dependencies depend on kernel configuration, enable them as needed:

    - libelf-dev when UNWINDER_ORC is set
    - libssl-dev for SYSTEM_TRUSTED_KEYRING

    Since the libssl-dev is needed for extract_cert binary, denote with
    :native to install the libssl-dev for the build machines architecture,
    rather than for the architecture of the kernel being built.

    Tested-by: Manivannan Sadhasivam
    Signed-off-by: Riku Voipio
    Reviewed-by: Ben Hutchings
    Acked-by: maximilian attems
    [masahiro.yamada: change 'flex' to 'flex | flex:native' ]
    Signed-off-by: Masahiro Yamada

    Riku Voipio
     

28 Feb, 2019

1 commit


20 Feb, 2019

1 commit


01 Dec, 2018

1 commit


11 Nov, 2018

2 commits

  • Commit 37c8a5fafa3b ("kbuild: consolidate Devicetree dtb build rules")
    moved the location of 'dtbs_install' target which caused dtbs to not be
    installed when building debian package with 'bindeb-pkg' target. Update
    the builddeb script to use the same logic that determines if there's a
    'dtbs_install' target which is presence of the arch dts directory. Also,
    use CONFIG_OF_EARLY_FLATTREE instead of CONFIG_OF as that's a better
    indication of whether we are building dtbs.

    This commit will also have the side effect of installing dtbs on any
    arch that has dts files. Previously, it was dependent on whether the
    arch defined 'dtbs_install'.

    Fixes: 37c8a5fafa3b ("kbuild: consolidate Devicetree dtb build rules")
    Reported-by: Nuno Gonçalves
    Signed-off-by: Rob Herring
    Signed-off-by: Masahiro Yamada

    Rob Herring
     
  • Since commit b41d920acff8 ("kbuild: deb-pkg: split generating packaging
    and build"), the build version of the kernel contained in a deb package
    is too low by 1.

    Prior to the bad commit, the kernel was built first, then the number
    in .version file was read out, and written into the debian control file.

    Now, the debian control file is created before the kernel is actually
    compiled, which is causing the version number mismatch.

    Let the mkdebian script pass KBUILD_BUILD_VERSION=${revision} to require
    the build system to use the specified version number.

    Fixes: b41d920acff8 ("kbuild: deb-pkg: split generating packaging and build")
    Reported-by: Doug Smythies
    Signed-off-by: Masahiro Yamada
    Tested-by: Doug Smythies

    Masahiro Yamada
     

06 Nov, 2018

2 commits

  • Ard Biesheuvel reports bindeb-pkg with O= option is broken in the
    following way:

    ...
    LD [M] sound/soc/rockchip/snd-soc-rk3399-gru-sound.ko
    LD [M] sound/soc/rockchip/snd-soc-rockchip-pcm.ko
    LD [M] sound/soc/rockchip/snd-soc-rockchip-rt5645.ko
    LD [M] sound/soc/rockchip/snd-soc-rockchip-spdif.ko
    LD [M] sound/soc/sh/rcar/snd-soc-rcar.ko
    fakeroot -u debian/rules binary
    make KERNELRELEASE=4.19.0-12677-g19beffaf7a99-dirty ARCH=arm64 KBUILD_SRC= intdeb-pkg
    /bin/bash /home/ard/linux/scripts/package/builddeb
    Makefile:600: include/config/auto.conf: No such file or directory
    ***
    *** Configuration file ".config" not found!
    ***
    *** Please run some configurator (e.g. "make oldconfig" or
    *** "make menuconfig" or "make xconfig").
    ***
    make[12]: *** [syncconfig] Error 1
    make[11]: *** [syncconfig] Error 2
    make[10]: *** [include/config/auto.conf] Error 2
    make[9]: *** [__sub-make] Error 2
    ...

    Prior to commit 80463f1b7bf9 ("kbuild: add --include-dir flag only
    for out-of-tree build"), both srctree and objtree were added to
    --include-dir redundantly, and the wrong code '$MAKE image_name'
    was working by relying on that. Now, the potential issue that had
    previously been hidden just showed up.

    '$MAKE image_name' recurses to the generated $(objtree)/Makefile and
    ends up with running in srctree, which is incorrect. It should be
    invoked with '-f $srctree/Makefile' (or KBUILD_SRC=) to be executed
    in objtree.

    Fixes: 80463f1b7bf9 ("kbuild: add --include-dir flag only for out-of-tree build")
    Reported-by: Ard Biesheuvel
    Signed-off-by: Masahiro Yamada
    Tested-by: Ard Biesheuvel

    Masahiro Yamada
     
  • Zhenzhong Duan reported that running 'make O=/build/kernel binrpm-pkg'
    failed with the following errors:

    Running 'make O=/build/kernel binrpm-pkg' failed with below two errors.

    Makefile:600: include/config/auto.conf: No such file or directory

    + cp make -C /mnt/root/kernel O=/build/kernel image_name make -f
    /mnt/root/kernel/Makefile ...
    cp: invalid option -- 'C'
    Try 'cp --help' for more information.

    Prior to commit 80463f1b7bf9 ("kbuild: add --include-dir flag only
    for out-of-tree build"), both srctree and objtree were added to
    --include-dir redundantly, and the wrong code 'make image_name'
    was working by relying on that. Now, the potential issue that had
    previously been hidden just showed up.

    'make image_name' recurses to the generated $(objtree)/Makefile and
    ends up with running in srctree, which is incorrect. It should be
    invoked with '-f $srctree/Makefile' (or KBUILD_SRC=) to be executed
    in objtree.

    Fixes: 80463f1b7bf9 ("kbuild: add --include-dir flag only for out-of-tree build")
    Reported-by: Zhenzhong Duan
    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

28 Jul, 2018

12 commits


19 Jul, 2018

2 commits


17 May, 2018

1 commit

  • There is multiple issues with the genaration of maintainer string

    It uses DEBEMAIL and EMAIL enviroment variables, which may contain angle brackets,
    creating invalid maintainer strings. The documented KBUILD_BUILD_USER and
    KBUILD_BUILD_HOST variables are not used. Undocumented and uncommon NAME
    variable is used. Refactor the Maintainer string to:

    - use EMAIL or DEBEMAIL directly if they are in form "name "
    - use KBUILD_BUILD_USER and KBUILD_BUILD_HOST if set before falling
    back to autodetection
    - no longer use NAME variable or the useless Anonymous string

    The logic is switched from multiline if/then/fi statements to compact
    shell variable substition commands.

    Reported-by: Mathieu Malaterre
    Signed-off-by: Riku Voipio
    Signed-off-by: Masahiro Yamada

    Riku Voipio
     

13 Apr, 2018

1 commit


07 Apr, 2018

1 commit

  • Move debian/ directory generation out of builddeb to a new script,
    mkdebian. The package build commands are kept in builddeb, which
    is now an internal command called from debian/rules.

    With these changes in place, we can now use dpkg-buildpackage from
    deb-pkg and bindeb-pkg removing need for handrolled source/changes
    generation.

    This patch is based on the criticism of the current state of builddeb
    discussed on:

    https://patchwork.kernel.org/patch/9656403/

    Signed-off-by: Riku Voipio
    Signed-off-by: Masahiro Yamada

    Riku Voipio