All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shuah Khan <shuahkh@osg.samsung.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Ingo Molnar <mingo@kernel.org>, David Ahern <dsahern@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Shuah Khan <shuahkh@osg.samsung.com>
Subject: Re: make -C tools clean failure on older systems
Date: Thu, 14 May 2015 09:39:43 -0600	[thread overview]
Message-ID: <5554C1BF.7000408@osg.samsung.com> (raw)
In-Reply-To: <20150514151225.GH23588@kernel.org>

On 05/14/2015 09:12 AM, Arnaldo Carvalho de Melo wrote:
> Hi,
> 
> 	In:
> 
>  -------------
> commit 67d8712dcc70aa16d8e14a52eb73870e3cbddfc2
> Author: Shuah Khan <shuahkh@osg.samsung.com>
> Date:   Wed Mar 18 11:57:39 2015 -0600
> 
>     selftests: Fix build failures when invoked from kselftest target
> 
>  -------------
> 
> You cleaned two variables using different methods, any reason for that?
> 
> I asked because the 'undefine' method causes it to fail in older
> systems:

The reason for this change is some tests fail to build when invoked
from the main Makefile level. The commit log explains the change:

Several tests that rely on implicit build rules fail to build,
when invoked from the main Makefile kselftest target. These
failures are due to --no-builtin-rules and --no-builtin-variables
options set in the inherited MAKEFLAGS.

--no-builtin-rules eliminates the use of built-in implicit rules
and --no-builtin-variables is for not defining built-in variables.
These two options override the use of implicit rules resulting in
build failures. In addition, inherited LDFLAGS result in build
failures and there is no need to define LDFLAGS.  Clear LDFLAGS
and MAKEFLAG when make is invoked from the main Makefile kselftest
target. Fixing this at selftests Makefile avoids changing the main
Makefile and keeps this change self contained at selftests level.

> 
> [acme@rhel5 linux]$ make -C tools/ clean
> <SNIP>
>   CLEAN    python
> make[1]: Leaving directory `/home/acme/git/linux/tools/perf'
>   DESCEND  testing/selftests
> make[1]: Entering directory
> `/home/acme/git/linux/tools/testing/selftests'
> Makefile:30: *** missing separator.  Stop.
> make[1]: Leaving directory
> `/home/acme/git/linux/tools/testing/selftests'
> make: *** [selftests_clean] Error 2
> make: Leaving directory `/home/acme/git/linux/tools'
> 
>  ----------------------------------
> 
> [acme@rhel5 linux]$ make --version
> GNU Make 3.81
> Copyright (C) 2006  Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.
> There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> 
> This program built for x86_64-redhat-linux-gnu
> [acme@rhel5 linux]$
> 
> Wonder if it would be ok to use:
> 
> diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
> index 95abddcd7839..f76830643086 100644
> --- a/tools/testing/selftests/Makefile
> +++ b/tools/testing/selftests/Makefile
> @@ -27,7 +27,7 @@ TARGETS_HOTPLUG += memory-hotplug
>  # Makefile to avoid test build failures when test
>  # Makefile doesn't have explicit build rules.
>  ifeq (1,$(MAKELEVEL))
> -undefine LDFLAGS
> +override LDFLAGS =
>  override MAKEFLAGS =
>  endif

I recall testing with override and remember it to not work. If you would
like experiment with it, feel free to send a patch with that change. My
make version is very new:

make --version
GNU Make 4.0
Built for x86_64-pc-linux-gnu

You have to run make kselftest from the main kernel Makefile to see
the build failures that undefine LDFLAGS fixed.

thanks,
-- Shuah



-- 
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978

  reply	other threads:[~2015-05-14 15:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-14 15:12 make -C tools clean failure on older systems Arnaldo Carvalho de Melo
2015-05-14 15:39 ` Shuah Khan [this message]
2015-05-14 15:54   ` Arnaldo Carvalho de Melo
2015-05-14 17:42     ` Ingo Molnar
2015-05-14 20:00       ` Arnaldo Carvalho de Melo
2015-05-14 18:29     ` Shuah Khan
2015-05-14 19:48       ` Arnaldo Carvalho de Melo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5554C1BF.7000408@osg.samsung.com \
    --to=shuahkh@osg.samsung.com \
    --cc=acme@kernel.org \
    --cc=dsahern@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mpe@ellerman.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.