1. 02 May, 2019 1 commit
    • Masahiro Yamada's avatar
      kbuild: simplify ld-option implementation · 1f855871
      Masahiro Yamada authored
      commit 0294e6f4 upstream.
      Currently, linker options are tested by the coordination of $(CC) and
      $(LD) because $(LD) needs some object to link.
      As commit 86a9df59 ("kbuild: fix linker feature test macros when
      cross compiling with Clang") addressed, we need to make sure $(CC)
      and $(LD) agree the underlying architecture of the passed object.
      This could be a bit complex when we combine tools from different groups.
      For example, we can use clang for $(CC), but we still need to rely on
      GCC toolchain for $(LD).
      So, I was searching for a way of standalone testing of linker options.
      A trick I found is to use '-v'; this not only prints the version string,
      but also tests if the given option is recognized.
      If a given option is supported,
        $ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419
        GNU ld (Linaro_Binutils-2017.11)
        $ echo $?
      If unsupported,
        $ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419
        GNU ld (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 2.23.1
        aarch64-linux-gnu-ld: unrecognized option '--fix-cortex-a53-843419'
        aarch64-linux-gnu-ld: use the --help option for usage information
        $ echo $?
      Gold works likewise.
        $ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-843419
        GNU gold (Linaro_Binutils-2017.11 1.14
        masahiro@pug:~/ref/linux$ echo $?
        $ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-999999
        GNU gold (Linaro_Binutils-2017.11 1.14
        aarch64-linux-gnu-ld.gold: --fix-cortex-a53-999999: unknown option
        aarch64-linux-gnu-ld.gold: use the --help option for usage information
        $ echo $?
      LLD too.
        $ ld.lld -v --gc-sections
        LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
        $ echo $?
        $ ld.lld -v --fix-cortex-a53-843419
        LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
        $ echo $?
        $ ld.lld -v --fix-cortex-a53-999999
        ld.lld: error: unknown argument: --fix-cortex-a53-999999
        LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers)
        $ echo $?
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Tested-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      [nc: try-run-cached was added later, just use try-run, which is the
           current mainline state]
      Signed-off-by: default avatarNathan Chancellor <natechancellor@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 26 Sep, 2018 1 commit
    • Masahiro Yamada's avatar
      kbuild: add .DELETE_ON_ERROR special target · ee83ce18
      Masahiro Yamada authored
      [ Upstream commit 9c2af1c7 ]
      If Make gets a fatal signal while a shell is executing, it may delete
      the target file that the recipe was supposed to update.  This is needed
      to make sure that it is remade from scratch when Make is next run; if
      Make is interrupted after the recipe has begun to write the target file,
      it results in an incomplete file whose time stamp is newer than that
      of the prerequisites files.  Make automatically deletes the incomplete
      file on interrupt unless the target is marked .PRECIOUS.
      The situation is just the same as when the shell fails for some reasons.
      Usually when a recipe line fails, if it has changed the target file at
      all, the file is corrupted, or at least it is not completely updated.
      Yet the file’s time stamp says that it is now up to date, so the next
      time Make runs, it will not try to update that file.
      However, Make does not cater to delete the incomplete target file in
      this case.  We need to add .DELETE_ON_ERROR somewhere in the Makefile
      to request it.
      scripts/Kbuild.include seems a suitable place to add it because it is
      included from almost all sub-makes.
      Please note .DELETE_ON_ERROR is not effective for phony targets.
      The external module building should never ever touch the kernel tree.
      The following recipe fails if include/generated/autoconf.h is missing.
      However, include/config/auto.conf is not deleted since it is a phony
       PHONY += include/config/auto.conf
               $(Q)test -e include/generated/autoconf.h -a -e $@ || (          \
               echo >&2;                                                       \
               echo >&2 "  ERROR: Kernel configuration is invalid.";           \
               echo >&2 "         include/generated/autoconf.h or $@ are missing.";\
               echo >&2 "         Run 'make oldconfig && make prepare' on kernel src to fix it."; \
               echo >&2 ;                                                      \
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  3. 11 Jul, 2018 1 commit
    • Rasmus Villemoes's avatar
      Kbuild: fix # escaping in .cmd files for future Make · e8288549
      Rasmus Villemoes authored
      commit 9564a8cf upstream.
      I tried building using a freshly built Make (4.2.1-69-g8a731d1), but
      already the objtool build broke with
      orc_dump.c: In function ‘orc_dump’:
      orc_dump.c:106:2: error: ‘elf_getshnum’ is deprecated [-Werror=deprecated-declarations]
        if (elf_getshdrnum(elf, &nr_sections)) {
      Turns out that with that new Make, the backslash was not removed, so cpp
      didn't see a #include directive, grep found nothing, and
      -DLIBELF_USE_DEPRECATED was wrongly put in CFLAGS.
      Now, that new Make behaviour is documented in their NEWS file:
        * WARNING: Backward-incompatibility!
          Number signs (#) appearing inside a macro reference or function invocation
          no longer introduce comments and should not be escaped with backslashes:
          thus a call such as:
            foo := $(shell echo '#')
          is legal.  Previously the number sign needed to be escaped, for example:
            foo := $(shell echo '\#')
          Now this latter will resolve to "\#".  If you want to write makefiles
          portable to both versions, assign the number sign to a variable:
            C := \#
            foo := $(shell echo '$C')
          This was claimed to be fixed in 3.81, but wasn't, for some reason.
          To detect this change search for 'nocomment' in the .FEATURES variable.
      This also fixes up the two make-cmd instances to replace # with $(pound)
      rather than with \#. There might very well be other places that need
      similar fixup in preparation for whatever future Make release contains
      the above change, but at least this builds an x86_64 defconfig with the
      new make.
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. 24 Mar, 2018 1 commit
    • Nick Desaulniers's avatar
      kbuild: fix linker feature test macros when cross compiling with Clang · 957435b5
      Nick Desaulniers authored
      commit 86a9df59 upstream.
      I was not seeing my linker flags getting added when using ld-option when
      cross compiling with Clang. Upon investigation, this seems to be due to
      a difference in how GCC vs Clang handle cross compilation.
      GCC is configured at build time to support one backend, that is implicit
      when compiling.  Clang is explicit via the use of `-target <triple>` and
      ships with all supported backends by default.
      GNU Make feature test macros that compile then link will always fail
      when cross compiling with Clang unless Clang's triple is passed along to
      the compiler. For example:
      $ clang -x c /dev/null -c -o temp.o
      $ aarch64-linux-android/bin/ld -E temp.o
      unknown architecture of input file `temp.o' is incompatible with
      aarch64 output
      warning: cannot find entry symbol _start; defaulting to
      $ echo $?
      $ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o
      $ aarch64-linux-android/bin/ld -E temp.o
      warning: cannot find entry symbol _start; defaulting to 00000000004002e4
      $ echo $?
      This causes conditional checks that invoke $(CC) without the target
      triple, then $(LD) on the result, to always fail.
      Suggested-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Reviewed-by: default avatarMatthias Kaehlcke <mka@chromium.org>
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarGreg Hackmann <ghackmann@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 09 Aug, 2017 1 commit
  6. 25 Jun, 2017 2 commits
  7. 11 Apr, 2017 1 commit
  8. 30 Mar, 2017 1 commit
    • Josh Poimboeuf's avatar
      x86/build: Mostly disable '-maccumulate-outgoing-args' · 3f135e57
      Josh Poimboeuf authored
      The GCC '-maccumulate-outgoing-args' flag is enabled for most configs,
      mostly because of issues which are no longer relevant.  For most
      configs, and with most recent versions of GCC, it's no longer needed.
      Clarify which cases need it, and only enable it for those cases.  Also
      produce a compile-time error for the ftrace graph + mcount + '-Os' case,
      which will otherwise cause runtime failures.
      The main benefit of '-maccumulate-outgoing-args' is that it prevents an
      ugly prologue for functions which have aligned stacks.  But removing the
      option also has some benefits: more readable argument saves, smaller
      text size, and (presumably) slightly improved performance.
      Here are the object size savings for 32-bit and 64-bit defconfig
            text	   data	    bss	     dec	    hex	filename
        10006710	3543328	1773568	15323606	 e9d1d6	vmlinux.x86-32.before
         9706358	3547424	1773568	15027350	 e54c96	vmlinux.x86-32.after
            text	   data	    bss	     dec	    hex	filename
        10652105	4537576	 843776	16033457	 f4a6b1	vmlinux.x86-64.before
        10639629	4537576	 843776	16020981	 f475f5	vmlinux.x86-64.after
      That comes out to a 3% text size improvement on x86-32 and a 0.1% text
      size improvement on x86-64.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrew Lutomirski <luto@kernel.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/20170316193133.zrj6gug53766m6nn@trebleSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
  9. 14 Feb, 2017 1 commit
  10. 09 Aug, 2016 1 commit
    • Emese Revfy's avatar
      kbuild: no gcc-plugins during cc-option tests · d26e9414
      Emese Revfy authored
      The gcc-plugins arguments should not be included when performing
      cc-option tests.
      Steps to reproduce:
      1) make mrproper
      2) make defconfig
      4) enable FUNCTION_TRACER (it will select other options as well)
      5) make && make modules
      Build errors:
      MODPOST 18 modules
      ERROR: "__fentry__" [net/netfilter/xt_nat.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/xt_mark.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/xt_addrtype.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/xt_LOG.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/nf_nat_sip.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/nf_nat_irc.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/nf_nat_ftp.ko] undefined!
      ERROR: "__fentry__" [net/netfilter/nf_nat.ko] undefined!
      Reported-by: default avatarLaura Abbott <labbott@redhat.com>
      Signed-off-by: default avatarEmese Revfy <re.emese@gmail.com>
      [kees: renamed variable, clarified commit message]
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
  11. 18 Jul, 2016 2 commits
    • Arnd Bergmann's avatar
      Kbuild: don't add obj tree in additional includes · db547ef1
      Arnd Bergmann authored
      When building with separate object directories and driver specific
      Makefiles that add additional header include paths, Kbuild adjusts
      the gcc flags so that we include both the directory in the source
      tree and in the object tree.
      However, due to another bug I fixed earlier, this did not actually
      include the correct directory in the object tree, so we know that
      we only really need the source tree here. Also, including the
      object tree sometimes causes warnings about nonexisting directories
      when the include path only exists in the source.
      This changes the logic to only emit the -I argument for the srctree,
      not for objects. We still need both $(srctree)/$(src) and $(obj)
      though, so I'm adding them manually.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
    • Arnd Bergmann's avatar
      Kbuild: don't add ../../ to include path · b999596b
      Arnd Bergmann authored
      When we build with O=objdir and objdir is directly below the source tree,
      $(srctree) becomes '..'.
      When a Makefile adds a CFLAGS option like -Ipath/to/headers and
      we are building with a separate object directory, Kbuild tries to
      add two -I options, one for the source tree and one for the object
      tree. An absolute path is treated as a special case, and don't add
      this one twice. This also normally catches -I$(srctree)/$(src)
      as $(srctree) usually is an absolute directory like /home/arnd/linux/.
      The combination of the two behaviors however results in an invalid
      path name to be included: we get both ../$(src) and ../../$(src),
      the latter one pointing outside of the source tree, usually to a
      nonexisting directory. Building with 'make W=1' makes this obvious:
      cc1: error: ../../arch/arm/mach-s3c24xx/include: No such file or directory [-Werror=missing-include-dirs]
      This adds another special case, treating path names starting with ../
      like those starting with / so we don't try to prefix that with
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
  12. 10 May, 2016 2 commits
    • Masahiro Yamada's avatar
      kbuild: fix if_change and friends to consider argument order · 9c8fa9bc
      Masahiro Yamada authored
      Currently, arg-check is implemented as follows:
        arg-check = $(strip $(filter-out $(cmd_$(1)), $(cmd_$@)) \
                            $(filter-out $(cmd_$@),   $(cmd_$(1))) )
      This does not care about the order of arguments that appear in
      $(cmd_$(1)) and $(cmd_$@).  So, if_changed and friends never rebuild
      the target if only the argument order is changed.  This is a problem
      when the link order is changed.
        obj-y += foo.o
        obj-y += bar.o
        obj-y += bar.o
        obj-y += foo.o
      should be distinguished because the link order determines the probe
      order of drivers.  So, built-in.o should be rebuilt when the order
      of objects is changed.
      This commit fixes arg-check to compare the old/current commands
      including the argument order.
      Of course, this change has a side effect; Kbuild will react to the
      change of compile option order.  For example, "-DFOO -DBAR" and
      "-DBAR -DFOO" should give no difference to the build result, but
      false positive should be better than false negative.
      I am moving space_escape to the top of Kbuild.include just for a
      matter of preference.  In practical terms, space_escape can be
      defined after arg-check because arg-check uses "=" flavor, not ":=".
      Having said that, collecting convenient variables in one place makes
      sense from the point of readability.
      Chaining "%%%SPACE%%%" to "_-_SPACE_-_" is also a matter of taste
      at this point.  Actually, it can be arbitrary as long as it is an
      unlikely used string.  The only problem I see in "%%%SPACE%%%" is
      that "%" is a special character in "$(patsubst ...)" context.  This
      commit just uses "$(subst ...)" for arg-check, but I am fixing it now
      in case we might want to use it in $(patsubst ...) context in the
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
    • Nicolas Pitre's avatar
      kbuild: fix ksym_dep_filter when multiple EXPORT_SYMBOL() on the same line · f110e0fe
      Nicolas Pitre authored
      In kernel/cgroup.c there is:
          #define SUBSYS(_x)                                             \
              DEFINE_STATIC_KEY_TRUE(_x ## _cgrp_subsys_enabled_key);    \
              DEFINE_STATIC_KEY_TRUE(_x ## _cgrp_subsys_on_dfl_key);     \
              EXPORT_SYMBOL_GPL(_x ## _cgrp_subsys_enabled_key);         \
              EXPORT_SYMBOL_GPL(_x ## _cgrp_subsys_on_dfl_key);
      The expansion of this macro causes multiple EXPORT_SYMBOL_GPL() instances
      to appear on the same preprocessor line output, confusing the sed script
      expecting only one of them per line.  Unfortunately this can't be fixed
      nicely in the sed script as sed's regexp can't do non greedy matching.
      Fix this by turning any semicolon into a line break before filtering.
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
  13. 27 Apr, 2016 1 commit
  14. 29 Mar, 2016 2 commits
    • Nicolas Pitre's avatar
      kbuild: add fine grained build dependencies for exported symbols · c1a95fda
      Nicolas Pitre authored
      Like with kconfig options, we now have the ability to compile in and
      out individual EXPORT_SYMBOL() declarations based on the content of
      include/generated/autoksyms.h.  However we don't want the entire
      world to be rebuilt whenever that file is touched.
      Let's apply the same build dependency trick used for CONFIG_* symbols
      where the time stamp of empty files whose paths matching those symbols
      is used to trigger fine grained rebuilds. In our case the key is the
      symbol name passed to EXPORT_SYMBOL().
      However, unlike config options, we cannot just use fixdep to parse
      the source code for EXPORT_SYMBOL(ksym) because several variants exist
      and parsing them all in a separate tool, and keeping it in synch, is
      not trivially maintainable.  Furthermore, there are variants such as
      that are instanciated via a macro for which we can't easily determine
      the actual exported symbol name(s) short of actually running the
      preprocessor on them.
      Storing the symbol name string in a special ELF section doesn't work
      for targets that output assembly or preprocessed source.
      So the best way is really to leverage the preprocessor by having it
      output actual symbol names anchored by a special sequence that can be
      easily filtered out. Then the list of symbols is simply fed to fixdep
      to be merged with the other dependencies.
      That implies the preprocessor is executed twice for each source file.
      A previous attempt relied on a warning pragma for each EXPORT_SYMBOL()
      instance that was filtered apart from stderr by the build system with
      a sed script during the actual compilation pass. Unfortunately the
      preprocessor/compiler diagnostic output isn't stable between versions
      and this solution, although more efficient, was deemed too fragile.
      Because of the lowercasing performed by fixdep, there might be name
      collisions triggering spurious rebuilds for similar symbols. But this
      shouldn't be a big issue in practice. (This is the case for CONFIG_*
      symbols and I didn't want to be different here, whatever the original
      reason for doing so.)
      To avoid needless build overhead, the exported symbol name gathering is
      performed only when CONFIG_TRIM_UNUSED_KSYMS is selected.
      Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
    • Nicolas Pitre's avatar
      kbuild: de-duplicate fixdep usage · e4aca459
      Nicolas Pitre authored
      The generation and postprocessing of automatic dependency rules is
      duplicated in rule_cc_o_c, rule_as_o_S and if_changed_dep. Since
      this is not a trivial one-liner action, it is now abstracted under
      cmd_and_fixdep to simplify things and make future changes in this area
      In the rule_cc_o_c and rule_as_o_S cases that means the order of some
      commands has been altered, namely fixdep and related file manipulations
      are executed earlier, but they didn't depend on those commands that now
      execute later.
      Signed-off-by: default avatarNicolas Pitre <nico@linaro.org>
  15. 04 Mar, 2016 1 commit
    • Masahiro Yamada's avatar
      kbuild: suppress annoying "... is up to date." message · 2aedcd09
      Masahiro Yamada authored
      Under certain conditions, Kbuild shows "... is up to date" where
      if_changed or friends are used.
      For example, the incremental build of ARM64 Linux shows this message
      when the kernel image has not been updated.
        $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-
          CHK     include/config/kernel.release
          CHK     include/generated/uapi/linux/version.h
          CHK     include/generated/utsrelease.h
          CHK     include/generated/bounds.h
          CHK     include/generated/timeconst.h
          CHK     include/generated/asm-offsets.h
          CALL    scripts/checksyscalls.sh
          CHK     include/generated/compile.h
          CHK     kernel/config_data.h
        make[1]: `arch/arm64/boot/Image.gz' is up to date.
          Building modules, stage 2.
          MODPOST 0 modules
      The following is the build rule in arch/arm64/boot/Makefile:
        $(obj)/Image.gz: $(obj)/Image FORCE
                $(call if_changed,gzip)
      If the Image.gz is newer than the Image and the command line has not
      changed (i.e., $(any-prereq) and $(arg-check) are both empty), the
      build rule $(call if_changed,gzip) is evaluated to be empty, then
      GNU Make reports the target is up to date.  In order to make GNU Make
      quiet, we need to give it something to do, for example, "@:".  This
      should be fixed in the Kbuild core part rather than in each Makefile.
      Signed-off-by: Masahiro Yamada's avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
  16. 04 Sep, 2015 1 commit
  17. 14 Aug, 2015 1 commit
    • David Woodhouse's avatar
      modsign: Handle signing key in source tree · 3ee550f1
      David Woodhouse authored
      Since commit 1329e8cc ("modsign: Extract signing cert from
      CONFIG_MODULE_SIG_KEY if needed"), the build system has carefully coped
      with the signing key being specified as a relative path in either the
      source or or the build trees.
      However, the actual signing of modules has not worked if the filename
      is relative to the source tree.
      Fix that by moving the config_filename helper into scripts/Kbuild.include
      so that it can be used from elsewhere, and then using it in the top-level
      Makefile to find the signing key file.
      Kill the intermediate $(MODPUBKEY) and $(MODSECKEY) variables too, while
      we're at it. There's no need for them.
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
  18. 09 Jan, 2015 3 commits
  19. 03 Dec, 2014 1 commit
  20. 26 Nov, 2014 1 commit
  21. 21 Oct, 2014 1 commit
  22. 02 Oct, 2014 1 commit
  23. 07 Aug, 2014 1 commit
  24. 29 Mar, 2014 1 commit
  25. 14 Feb, 2014 1 commit
  26. 08 Apr, 2013 1 commit
    • Antony Pavlov's avatar
      kbuild: fix ld-option function · 5b83df2b
      Antony Pavlov authored
      The kbuild's ld-option function is broken because
      the command
        $(CC) /dev/null -c -o "$$TMPO"
      does not create object file!
      I have used a relatively old mips gcc 3.4.6 cross-compiler
      and a relatively new gcc 4.7.2 to check this fact
      but the results are the same.
        $ rm /tmp/1.o
        $ mips-linux-gcc /dev/null -c -o /tmp/1.o
        mips-linux-gcc: /dev/null: linker input file unused because linking not done
        $ ls -la /tmp/1.o
        ls: cannot access /tmp/1.o: No such file or directory
      We can easily fix the problem by adding
      the '-x c' compiler option.
        $ rm /tmp/1.o
        $ mips-linux-gcc -x c /dev/null -c -o /tmp/1.o
        $ ls -la /tmp/1.o
        -rw-r--r-- 1 antony antony 778 Apr  2 20:40 /tmp/1.o
      Also fix wrong ld-option example.
      Signed-off-by: default avatarAntony Pavlov <antonynpavlov@gmail.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  27. 05 Oct, 2012 1 commit
  28. 03 Oct, 2012 1 commit
    • Jean Delvare's avatar
      kbuild: Fix gcc -x syntax · b1e0d8b7
      Jean Delvare authored
      The correct syntax for gcc -x is "gcc -x assembler", not
      "gcc -xassembler". Even though the latter happens to work, the former
      is what is documented in the manual page and thus what gcc wrappers
      such as icecream do expect.
      This isn't a cosmetic change. The missing space prevents icecream from
      recognizing compilation tasks it can't handle, leading to silent kernel
      Besides me, credits go to Michael Matz and Dirk Mueller for
      investigating the miscompilation issue and tracking it down to this
      incorrect -x parameter syntax.
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: stable@vger.kernel.org
      Cc: Bernhard Walle <bernhard@bwalle.de>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  29. 24 Mar, 2012 1 commit
    • Bernhard Walle's avatar
      scripts/Kbuild.include: Fix portability problem of "echo -e" · 875de986
      Bernhard Walle authored
      "echo -e" is a GNU extension. When cross-compiling the kernel on a
      BSD-like operating system (Mac OS X in my case), this doesn't work.
      One could install a GNU version of echo, put that in the $PATH before
      the system echo and use "/usr/bin/env echo", but the solution with
      printf is simpler.
      Since it is no disadvantage on Linux, I hope that gets accepted even if
      cross-compiling the Linux kernel on another Unix operating system is
      quite a rare use case.
      Signed-off-by: default avatarBernhard Walle <bernhard@bwalle.de>
      Andreas Bießmann <andreas@biessmann.de>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  30. 09 Jun, 2011 1 commit
  31. 16 May, 2011 1 commit
    • Michal Marek's avatar
      kbuild: make KBUILD_NOCMDDEP=1 handle empty built-in.o · c4d5ee13
      Michal Marek authored
      Based on a patch by Rabin Vincent.
      Fix building with KBUILD_NOCMDDEP=1, which currently does not work
      because it does not build built-in.o with no dependencies:
        LD      fs/notify/built-in.o
      ld: cannot find fs/notify/dnotify/built-in.o: No such file or directory
      ld: cannot find fs/notify/inotify/built-in.o: No such file or directory
      ld: cannot find fs/notify/fanotify/built-in.o: No such file or directory
      Reported-and-tested-by: default avatarRabin Vincent <rabin@rab.in>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  32. 03 May, 2011 1 commit
  33. 20 Apr, 2011 1 commit
  34. 12 Dec, 2009 1 commit
    • Michal Marek's avatar
      kbuild: generate modules.builtin · bc081dd6
      Michal Marek authored
      To make it easier for module-init-tools and scripts like mkinitrd to
      distinguish builtin and missing modules, install a modules.builtin file
      listing all builtin modules. This is done by generating an additional
      config file (tristate.conf) with tristate options set to uppercase 'Y'
      or 'M'. If we source that config file, the builtin modules appear in
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>