13 Jan, 2019

1 commit

  • commit 7ed1c1901fe52e6c5828deb155920b44b0adabb1 upstream.

    Currently a number of Makefiles break when used with toolchains that
    pass extra flags in CC and other cross-compile related variables (such
    as --sysroot).

    Thus we get this error when we use a toolchain that puts --sysroot in
    the CC var:

    ~/src/linux/tools$ make iio
    [snip]
    iio_event_monitor.c:18:10: fatal error: unistd.h: No such file or directory
    #include
    ^~~~~~~~~~

    This occurs because we clobber several env vars related to
    cross-compiling with lines like this:

    CC = $(CROSS_COMPILE)gcc

    Although this will point to a valid cross-compiler, we lose any extra
    flags that might exist in the CC variable, which can break toolchains
    that rely on them (for example, those that use --sysroot).

    This easily shows up using a Yocto SDK:

    $ . [snip]/sdk/environment-setup-cortexa8hf-neon-poky-linux-gnueabi

    $ echo $CC
    arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard
    -mcpu=cortex-a8
    --sysroot=[snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi

    $ echo $CROSS_COMPILE
    arm-poky-linux-gnueabi-

    $ echo ${CROSS_COMPILE}gcc
    krm-poky-linux-gnueabi-gcc

    Although arm-poky-linux-gnueabi-gcc is a cross-compiler, we've lost the
    --sysroot and other flags that enable us to find the right libraries to
    link against, so we can't find unistd.h and other libraries and headers.
    Normally with the --sysroot flag we would find unistd.h in the sdk
    directory in the sysroot:

    $ find [snip]/sdk/sysroots -path '*/usr/include/unistd.h'
    [snip]/sdk/sysroots/cortexa8hf-neon-poky-linux-gnueabi/usr/include/unistd.h

    The perf Makefile adds CC = $(CROSS_COMPILE)gcc if and only if CC is not
    already set, and it compiles correctly with the above toolchain.

    So, generalize the logic that perf uses in the common Makefile and
    remove the manual CC = $(CROSS_COMPILE)gcc lines from each Makefile.

    Note that this patch does not fix cross-compile for all the tools (some
    have other bugs), but it does fix it for all except usb and acpi, which
    still have other unrelated issues.

    I tested both with and without the patch on native and cross-build and
    there appear to be no regressions.

    Link: http://lkml.kernel.org/r/20180107214028.23771-1-martin@martingkelly.com
    Signed-off-by: Martin Kelly
    Acked-by: Mark Brown
    Cc: Tejun Heo
    Cc: Li Zefan
    Cc: Johannes Weiner
    Cc: Linus Walleij
    Cc: "K. Y. Srinivasan"
    Cc: Haiyang Zhang
    Cc: Stephen Hemminger
    Cc: Jonathan Cameron
    Cc: Pali Rohar
    Cc: Richard Purdie
    Cc: Jacek Anaszewski
    Cc: Pavel Machek
    Cc: Peter Zijlstra
    Cc: Ingo Molnar
    Cc: Arnaldo Carvalho de Melo
    Cc: Robert Moore
    Cc: Lv Zheng
    Cc: "Rafael J. Wysocki"
    Cc: Greg Kroah-Hartman
    Cc: Valentina Manea
    Cc: Shuah Khan
    Cc: Mario Limonciello
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds
    Cc: Ignat Korchagin
    Signed-off-by: Greg Kroah-Hartman

    Martin Kelly
     

11 Jul, 2018

1 commit

  • commit 9564a8cf422d7b58f6e857e3546d346fa970191e 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
    Signed-off-by: Rasmus Villemoes
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Greg Kroah-Hartman

    Rasmus Villemoes
     

03 Nov, 2017

1 commit

  • …el/git/gregkh/driver-core

    Pull initial SPDX identifiers from Greg KH:
    "License cleanup: add SPDX license identifiers to some files

    Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the
    'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally
    binding shorthand, which can be used instead of the full boiler plate
    text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart
    and Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset
    of the use cases:

    - file had no licensing information it it.

    - file was a */uapi/* one with no licensing information in it,

    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to
    license had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied
    to a file was done in a spreadsheet of side by side results from of
    the output of two independent scanners (ScanCode & Windriver)
    producing SPDX tag:value files created by Philippe Ombredanne.
    Philippe prepared the base worksheet, and did an initial spot review
    of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537
    files assessed. Kate Stewart did a file by file comparison of the
    scanner results in the spreadsheet to determine which SPDX license
    identifier(s) to be applied to the file. She confirmed any
    determination that was not immediately clear with lawyers working with
    the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:

    - Files considered eligible had to be source code files.

    - Make and config files were included as candidates if they contained
    >5 lines of source

    - File already had some variant of a license header in it (even if <5
    lines).

    All documentation files were explicitly excluded.

    The following heuristics were used to determine which SPDX license
    identifiers to apply.

    - when both scanners couldn't find any license traces, file was
    considered to have no license information in it, and the top level
    COPYING file license applied.

    For non */uapi/* files that summary was:

    SPDX license identifier # files
    ---------------------------------------------------|-------
    GPL-2.0 11139

    and resulted in the first patch in this series.

    If that file was a */uapi/* path one, it was "GPL-2.0 WITH
    Linux-syscall-note" otherwise it was "GPL-2.0". Results of that
    was:

    SPDX license identifier # files
    ---------------------------------------------------|-------
    GPL-2.0 WITH Linux-syscall-note 930

    and resulted in the second patch in this series.

    - if a file had some form of licensing information in it, and was one
    of the */uapi/* ones, it was denoted with the Linux-syscall-note if
    any GPL family license was found in the file or had no licensing in
    it (per prior point). Results summary:

    SPDX license identifier # files
    ---------------------------------------------------|------
    GPL-2.0 WITH Linux-syscall-note 270
    GPL-2.0+ WITH Linux-syscall-note 169
    ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
    ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
    LGPL-2.1+ WITH Linux-syscall-note 15
    GPL-1.0+ WITH Linux-syscall-note 14
    ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
    LGPL-2.0+ WITH Linux-syscall-note 4
    LGPL-2.1 WITH Linux-syscall-note 3
    ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
    ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

    and that resulted in the third patch in this series.

    - when the two scanners agreed on the detected license(s), that
    became the concluded license(s).

    - when there was disagreement between the two scanners (one detected
    a license but the other didn't, or they both detected different
    licenses) a manual inspection of the file occurred.

    - In most cases a manual inspection of the information in the file
    resulted in a clear resolution of the license that should apply
    (and which scanner probably needed to revisit its heuristics).

    - When it was not immediately clear, the license identifier was
    confirmed with lawyers working with the Linux Foundation.

    - If there was any question as to the appropriate license identifier,
    the file was flagged for further research and to be revisited later
    in time.

    In total, over 70 hours of logged manual review was done on the
    spreadsheet to determine the SPDX license identifiers to apply to the
    source files by Kate, Philippe, Thomas and, in some cases,
    confirmation by lawyers working with the Linux Foundation.

    Kate also obtained a third independent scan of the 4.13 code base from
    FOSSology, and compared selected files where the other two scanners
    disagreed against that SPDX file, to see if there was new insights.
    The Windriver scanner is based on an older version of FOSSology in
    part, so they are related.

    Thomas did random spot checks in about 500 files from the spreadsheets
    for the uapi headers and agreed with SPDX license identifier in the
    files he inspected. For the non-uapi files Thomas did random spot
    checks in about 15000 files.

    In initial set of patches against 4.14-rc6, 3 files were found to have
    copy/paste license identifier errors, and have been fixed to reflect
    the correct identifier.

    Additionally Philippe spent 10 hours this week doing a detailed manual
    inspection and review of the 12,461 patched files from the initial
    patch version early this week with:

    - a full scancode scan run, collecting the matched texts, detected
    license ids and scores

    - reviewing anything where there was a license detected (about 500+
    files) to ensure that the applied SPDX license was correct

    - reviewing anything where there was no detection but the patch
    license was not GPL-2.0 WITH Linux-syscall-note to ensure that the
    applied SPDX license was correct

    This produced a worksheet with 20 files needing minor correction. This
    worksheet was then exported into 3 different .csv files for the
    different types of files to be modified.

    These .csv files were then reviewed by Greg. Thomas wrote a script to
    parse the csv files and add the proper SPDX tag to the file, in the
    format that the file expected. This script was further refined by Greg
    based on the output to detect more types of files automatically and to
    distinguish between header and source .c files (which need different
    comment types.) Finally Greg ran the script using the .csv files to
    generate the patches.

    Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
    Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
    Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>"

    * tag 'spdx_identifiers-4.14-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core:
    License cleanup: add SPDX license identifier to uapi header files with a license
    License cleanup: add SPDX license identifier to uapi header files with no license
    License cleanup: add SPDX GPL-2.0 license identifier to files with no license

    Linus Torvalds
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

07 Oct, 2017

1 commit

  • I thought commit 8e9b46679923 ("kbuild: use $(abspath ...) instead of
    $(shell cd ... && /bin/pwd)") was a safe conversion, but it changed
    the behavior.

    $(abspath ...) / $(realpath ...) does not expand shell special
    characters, such as '~'.

    Here is a simple Makefile example:

    ---------------->8----------------
    $(info /bin/pwd: $(shell cd ~/; /bin/pwd))
    $(info abspath: $(abspath ~/))
    $(info realpath: $(realpath ~/))
    all:
    @:
    ---------------->8----------------

    $ make
    /bin/pwd: /home/masahiro
    abspath: /home/masahiro/workspace/~
    realpath:

    This can be a real problem if 'make O=~/foo' is invoked from another
    Makefile or primitive shell like dash.

    This commit partially reverts 8e9b46679923.

    Fixes: 8e9b46679923 ("kbuild: use $(abspath ...) instead of $(shell cd ... && /bin/pwd)")
    Reported-by: Julien Grall
    Signed-off-by: Masahiro Yamada
    Tested-by: Julien Grall

    Masahiro Yamada
     

15 Sep, 2017

1 commit

  • Pull Kbuild updates from Masahiro Yamada:

    - Use Make-builtin $(abspath ...) helper to get absolute path

    - Add W=2 extra warning option to detect unused macros

    - Use more KCONFIG_CONFIG instead hard-coded .config

    - Fix bugs of tar*-pkg targets

    * tag 'kbuild-v4.14' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
    kbuild: buildtar: do not print successful message if tar returns error
    kbuild: buildtar: fix tar error when CONFIG_MODULES is disabled
    kbuild: Use KCONFIG_CONFIG in buildtar
    Kbuild: enable -Wunused-macros warning for "make W=2"
    kbuild: use $(abspath ...) instead of $(shell cd ... && /bin/pwd)

    Linus Torvalds
     

01 Sep, 2017

1 commit

  • Kbuild conventionally uses $(shell cd ... && /bin/pwd) idiom to get
    the absolute path of the directory because GNU Make 3.80, the minimal
    supported version at that time, did not support $(abspath ...) or
    $(realpath ...).

    Commit 37d69ee30808 ("docs: bump minimal GNU Make version to 3.81")
    dropped the GNU Make 3.80 support, so we are now allowed to use those
    make-builtin helpers.

    This conversion will provide better portability without relying on
    the pwd command or its location /bin/pwd.

    I am intentionally using $(realpath ...) instead $(abspath ...) in
    some places. The difference between the two is $(realpath ...)
    returns an empty string if the given path does not exist. It is
    convenient in places where we need to error-out if the makefile fails
    to create an output directory.

    Signed-off-by: Masahiro Yamada
    Acked-by: Thierry Reding

    Masahiro Yamada
     

29 Aug, 2017

1 commit

  • Prior to this patch, make scripts tested for CLANG with ifeq ($(CC),
    clang), failing to detect CLANG binaries with different names. Fix it by
    testing for the existence of __clang__ macro in the list of compiler
    defined macros.

    Signed-off-by: David Carrillo-Cisneros
    Acked-by: Jiri Olsa
    Cc: Alexander Shishkin
    Cc: Paul Turner
    Cc: Stephane Eranian
    Link: http://lkml.kernel.org/r/20170827075442.108534-5-davidcc@google.com
    Signed-off-by: Arnaldo Carvalho de Melo

    David Carrillo-Cisneros
     

06 Jun, 2017

1 commit

  • This allows to detect -s (--silent) option without checking GNU Make
    version.

    As commit e36aaea28972 ("kbuild: Fix silent builds with make-4")
    pointed out, GNU Make 4.x changed the way/order it presents the
    command line options into MAKEFLAGS.

    In Make 3.8x, 's' is always the first in a group of short options.
    The group may be prefixed with '-' in some cases.

    In Make 4.x, 's' is always the last in a group of short options.

    As commit e6ac89fabd03 ("kbuild: Correctly deal with make options
    which contain an 's'") addressed, we also need to deal with long
    options that contain 's', like --warn-undefined-variables.

    Test cases:

    [1] command line input: make --silent
    -> MAKEFLAGS for Make 3.8x: s
    -> MAKEFLAGS for Make 4.x : s

    [2] command line input: make -srR
    -> MAKEFLAGS for Make 3.8x: sRr
    -> MAKEFLAGS for Make 4.x : rRs

    [3] command line input: make -s -rR --warn-undefined-variables
    -> MAKEFLAGS for Make 3.8x: --warn-undefined-variables -sRr
    -> MAKEFLAGS for Make 4.x : rRs --warn-undefined-variables

    My idea to cater to all the cases more easily is to filter out long
    options (--%), then search 's' with $(findstring ...). This way will
    be more future-proof even if future versions of Make put 's' in the
    middle of the group.

    Signed-off-by: Masahiro Yamada

    Masahiro Yamada
     

04 Mar, 2017

1 commit


14 Feb, 2017

1 commit


27 Jan, 2017

1 commit

  • When doing a kernel build with 'make -s', everything is silenced except
    the objtool build. That's because the tools tree support for silent
    builds is some combination of missing and broken.

    Three changes are needed to fix it:

    - Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the
    tools Makefiles can see it.

    - tools/scripts/Makefile.include: fix the tools Makefiles' ability to
    recognize '-s'. The MAKE_VERSION and MAKEFLAGS checks are copied from
    the top-level Makefile. This silences the "DESCEND objtool" message.

    - tools/build/Makefile.build: add support to the tools Build files for
    recognizing '-s'. Again the MAKE_VERSION and MAKEFLAGS checks are
    copied from the top-level Makefile. This silences all the object
    compile/link messages.

    Reported-and-Tested-by: Peter Zijlstra
    Signed-off-by: Josh Poimboeuf
    Cc: Jiri Olsa
    Cc: Michal Marek
    Link: http://lkml.kernel.org/r/e8967562ef640c3ae9a76da4ae0f4e47df737c34.1484799200.git.jpoimboe@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Josh Poimboeuf
     

23 Jul, 2016

2 commits

  • The objtool build fails in a cross-compiled environment on a non-x86
    host with "ARCH=x86_64":

    tools/objtool/objtool-in.o: In function `decode_instructions':
    tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction'

    We could override the ARCH environment variable and change it back to
    x86, similar to what the objtool Makefile was doing before; but it's
    tricky to override environment variables consistently.

    Instead, take a similar approach used by the Linux top-level Makefile
    and introduce a SRCARCH Makefile variable which evaluates to "x86" when
    ARCH is either "x86_64" or "x86".

    Reported-by: Stephen Rothwell
    Signed-off-by: Josh Poimboeuf
    Cc: Andy Lutomirski
    Cc: H. Peter Anvin
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/20160722191920.ej62fnspnqurbaa7@treble
    Signed-off-by: Arnaldo Carvalho de Melo

    Josh Poimboeuf
     
  • For tools that needs to be always compiled with the host headers.

    Cc: Adrian Hunter
    Cc: David Ahern
    Cc: Jiri Olsa
    Cc: Josh Poimboeuf
    Cc: Namhyung Kim
    Cc: Stephen Rothwell
    Cc: Wang Nan
    Link: http://lkml.kernel.org/n/tip-907q32k2nep6q670dkxypmu6@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Arnaldo Carvalho de Melo
     

19 Mar, 2016

1 commit


12 Jan, 2016

1 commit

  • After this patch other directories can use this architecture detector
    without directly including it from perf's directory. Libbpf would
    utilize it to get proper $(ARCH) so it can receive correct uapi include
    directory.

    Tested-by: Naveen N. Rao
    Acked-by: Jiri Olsa
    Cc: Sukadev Bhattiprolu
    Cc: Zefan Li
    Cc: pi3orama@163.com
    Signed-off-by: Wang Nan
    Link: http://lkml.kernel.org/r/1452520124-2073-8-git-send-email-wangnan0@huawei.com
    [ Add missing srctree definition in tests/make ]
    Signed-off-by: Arnaldo Carvalho de Melo

    Wang Nan
     

20 Dec, 2013

2 commits

  • Adding global QUIET_CC_FPIC build output variable and getting rid of
    local print_fpic_compile and print_plugin_obj_compile.

    Signed-off-by: Jiri Olsa
    Cc: Corey Ashford
    Cc: David Ahern
    Cc: Frederic Weisbecker
    Cc: Ingo Molnar
    Cc: Namhyung Kim
    Cc: Paul Mackerras
    Cc: Peter Zijlstra
    Cc: Steven Rostedt
    Link: http://lkml.kernel.org/r/1387460527-15030-6-git-send-email-jolsa@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Jiri Olsa
     
  • Moving QUIET_(CLEAN|INSTAL) variables into:

    tools/scripts/Makefile.include

    to be usable by other tools. The change to use them in libtraceevent is
    in following patches.

    Signed-off-by: Jiri Olsa
    Cc: Corey Ashford
    Cc: David Ahern
    Cc: Frederic Weisbecker
    Cc: Ingo Molnar
    Cc: Namhyung Kim
    Cc: Paul Mackerras
    Cc: Peter Zijlstra
    Cc: Steven Rostedt
    Link: http://lkml.kernel.org/r/1387460527-15030-3-git-send-email-jolsa@redhat.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Jiri Olsa
     

11 Oct, 2013

2 commits

  • The various build lines from libtraceevent and perf mix up during a
    parallel build and produce unaligned output like:

    CC builtin-buildid-list.o
    CC builtin-buildid-cache.o
    CC builtin-list.o
    CC FPIC trace-seq.o
    CC builtin-record.o
    CC FPIC parse-filter.o
    CC builtin-report.o
    CC builtin-stat.o
    CC FPIC parse-utils.o
    CC FPIC kbuffer-parse.o
    CC builtin-timechart.o
    CC builtin-top.o
    CC builtin-script.o
    BUILD STATIC LIB libtraceevent.a
    CC builtin-probe.o
    CC builtin-kmem.o
    CC builtin-lock.o

    To solve this, harmonize all the build message alignments to be similar
    to the kernel's kbuild output: prefixed by two spaces and 11-char wide.

    After the patch the output looks pretty tidy, even if output lines get
    mixed up:

    CC builtin-annotate.o
    FLAGS: * new build flags or cross compiler
    CC builtin-bench.o
    AR liblk.a
    CC bench/sched-messaging.o
    CC FPIC event-parse.o
    CC bench/sched-pipe.o
    CC FPIC trace-seq.o
    CC bench/mem-memcpy.o
    CC bench/mem-memset.o
    CC FPIC parse-filter.o
    CC builtin-diff.o
    CC builtin-evlist.o
    CC builtin-help.o

    Signed-off-by: Ingo Molnar
    Cc: David Ahern
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/1381312169-17354-3-git-send-email-mingo@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Ingo Molnar
     
  • 'make clean' used to show all the rm lines, which isn't really
    informative in any way and spams the console.

    Implement summary output:

    comet:~/tip/tools/perf> make clean
    CLEAN libtraceevent
    CLEAN liblk
    CLEAN config
    CLEAN core-objs
    CLEAN core-progs
    CLEAN core-gen
    CLEAN Documentation
    CLEAN python

    'make clean V=1' will still show the old, detailed output.

    Signed-off-by: Ingo Molnar
    Cc: David Ahern
    Cc: Jiri Olsa
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/1381312169-17354-2-git-send-email-mingo@kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Ingo Molnar
     

09 Jul, 2013

1 commit


16 Mar, 2013

2 commits

  • It looks at O= and adjusts the $(OUTPUT) variable based on what the
    output directory will be. However, when O is defined but empty, it
    wrongly becomes the user's $HOME dir which is not what we want. So check
    it is not empty before working with it further.

    Signed-off-by: Borislav Petkov
    Cc: Ingo Molnar
    Cc: Steven Rostedt
    Link: http://lkml.kernel.org/r/1361374353-30385-4-git-send-email-bp@alien8.de
    Signed-off-by: Arnaldo Carvalho de Melo

    Borislav Petkov
     
  • We need to hand down parallel build options like the internal make
    --jobserver-fds one so that parallel builds can also happen when
    building perf from the toplevel directory.

    Make it so #1!

    Signed-off-by: Borislav Petkov
    Cc: Ingo Molnar
    Cc: Steven Rostedt
    Link: http://lkml.kernel.org/r/1361374353-30385-3-git-send-email-bp@alien8.de
    Signed-off-by: Arnaldo Carvalho de Melo

    Borislav Petkov
     

20 Nov, 2012

3 commits

  • Fixing:

    [acme@sandy linux]$ cd tools
    [acme@sandy tools]$ make clean
    DESCEND power/cpupower
    CC lib/cpufreq.o
    CC lib/sysfs.o
    LD libcpupower.so.0.0.0
    CC utils/helpers/amd.o
    utils/helpers/amd.c:7:21: error: pci/pci.h: No such file or directory
    In file included from utils/helpers/amd.c:9:
    ./utils/helpers/helpers.h:137: warning: ‘struct pci_access’ declared inside parameter list
    ./utils/helpers/helpers.h:137: warning: its scope is only this definition or declaration, which is probably not what you want
    ./utils/helpers/helpers.h:139: warning: ‘struct pci_access’ declared inside parameter list
    utils/helpers/amd.c: In function ‘amd_pci_get_num_boost_states’:
    utils/helpers/amd.c:120: warning: passing argument 1 of ‘pci_slot_func_init’ from incompatible pointer type
    ./utils/helpers/helpers.h:138: note: expected ‘struct pci_access **’ but argument is of type ‘struct pci_access **’
    utils/helpers/amd.c:125: warning: implicit declaration of function ‘pci_read_byte’
    utils/helpers/amd.c:132: warning: implicit declaration of function ‘pci_cleanup’
    make[1]: *** [utils/helpers/amd.o] Error 1
    make: *** [cpupower_clean] Error 2
    [acme@sandy tools]$

    Reported-by: Arnaldo Carvalho de Melo
    Signed-off-by: David Howells
    Cc: Borislav Petkov
    Cc: Ingo Molnar
    Cc: Linus Torvalds
    Cc: Namhyung Kim
    Cc: Paul Mackerras
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/n/tip-tviyimq6x6nm77sj5lt4t19f@git.kernel.org
    Signed-off-by: Arnaldo Carvalho de Melo

    David Howells
     
  • Honour the O= flag that was passed to a higher level Makefile and then passed
    down as part of a tool build.

    To make this work, the top-level Makefile passes the original O= flag and
    subdir=tools to the tools/Makefile, and that in turn passes
    subdir=$(O)/$(subdir)/foodir when building tool foo in directory
    $(O)/$(subdir)/foodir (where the intervening slashes aren't added if an
    element is missing).

    For example, take perf. This is found in tools/perf/. Assume we're building
    into directory ~/zebra/, so we pass O=~/zebra to make. Dependening on where
    we run the build from, we see:

    make run in dir $(OUTPUT) dir
    ======================= ==================
    linux ~/zebra/tools/perf/
    linux/tools ~/zebra/perf/
    linux/tools/perf ~/zebra/

    and if O= is not set, we get:

    make run in dir $(OUTPUT) dir
    ======================= ==================
    linux linux/tools/perf/
    linux/tools linux/tools/perf/
    linux/tools/perf linux/tools/perf/

    The output directories are created by the descend function if they don't
    already exist.

    Signed-off-by: David Howells
    Cc: Borislav Petkov
    Cc: Ingo Molnar
    Cc: Linus Torvalds
    Cc: Namhyung Kim
    Cc: Paul Mackerras
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/1378.1352379110@warthog.procyon.org.uk
    Signed-off-by: Arnaldo Carvalho de Melo

    David Howells
     
  • Define a Makefile function that can be called with $(call ...) to wrap
    the subdir make invocations in tools/Makefile.

    This will allow us in the next patch to insert bits in there to honour
    O= flags when called from the top-level Makefile.

    Signed-off-by: David Howells
    Cc: Borislav Petkov
    Cc: Ingo Molnar
    Cc: Linus Torvalds
    Cc: Namhyung Kim
    Cc: Paul Mackerras
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/1378.1352379110@warthog.procyon.org.uk
    Signed-off-by: Arnaldo Carvalho de Melo

    David Howells
     

17 Aug, 2012

1 commit

  • When I did a compile of perf using a relative path for the output
    directory, the build failed when it tried to compile libtraceevent. This
    is because it continues to use the same relative path when the new
    working directory is in a different path.

    SUBDIR ../lib/traceevent/
    /bin/sh: line 0: cd: ../../../nobackup/perf/: No such file or directory
    Makefile:74: *** output directory "../../../nobackup/perf/" does not exist. Stop.
    make: *** [../../../nobackup/perf///libtraceevent.a] Error 2

    Make the path used an absolute path when building perf with O=.

    Boris:

    Teach Makefile to check whether the supplied O= directory exists and
    bail out if not. Reportedly, kernel dudes are idiots and need to be
    guarded so as not to shoot themselves in the foot when playing in the
    sandbox.

    Signed-off-by: Borislav Petkov
    Signed-off-by: Steven Rostedt
    Acked-by: Steven Rostedt
    Cc: Ingo Molnar
    Cc: Namhyung Kim
    Cc: Peter Zijlstra
    Link: http://lkml.kernel.org/r/20120815163923.GD15989@aftab.osrc.amd.com
    Signed-off-by: Arnaldo Carvalho de Melo

    Steven Rostedt
     

25 Apr, 2012

1 commit

  • Have building perf also build libtraceevent.a. Currently, perf does
    not use the code within libtraceevent.a, but it soon will.

    Signed-off-by: Steven Rostedt
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Peter Zijlstra
    Cc: Arnaldo Carvalho de Melo
    Cc: Steven Rostedt
    Cc: Borislav Petkov
    Cc: Jiri Olsa
    Cc: Arun Sharma
    Cc: Namhyung Kim
    Signed-off-by: Frederic Weisbecker

    Steven Rostedt
     

12 Apr, 2012

2 commits

  • Use += instead of the bash syntax, as Sam Ravnborg suggests. Also, sort
    the -W options alphabetically and (... keep them sorted).

    Suggested-by: Sam Ravnborg
    Signed-off-by: Borislav Petkov
    Cc: Ingo Molnar
    Cc: Michal Marek
    Cc: Sam Ravnborg
    Link: http://lkml.kernel.org/r/1334162178-17152-3-git-send-email-bp@amd64.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Borislav Petkov
     
  • Put generic enough build settings which could be reused by other tools
    into a common Makefile.include file.

    This commit reintroduces QUIET_SUBDIR{0,1} (see a3d1ee10d1bf) which are
    going to be used in the following patches.

    Signed-off-by: Borislav Petkov
    Cc: Ingo Molnar
    Cc: Michal Marek
    Cc: Sam Ravnborg
    Link: http://lkml.kernel.org/r/1334162178-17152-2-git-send-email-bp@amd64.org
    Signed-off-by: Arnaldo Carvalho de Melo

    Borislav Petkov