All of lore.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <rdunlap@infradead.org>
To: Michal Marek <mmarek@suse.cz>,
	Richard Weinberger <richard.weinberger@gmail.com>
Cc: linux-kbuild@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH v2 3/5] kbuild: Use relative path for $(objtree)
Date: Mon, 09 Jun 2014 15:24:11 -0700	[thread overview]
Message-ID: <5396340B.6060804@infradead.org> (raw)
In-Reply-To: <539631CC.9040002@suse.cz>

On 06/09/14 15:14, Michal Marek wrote:
> Dne 9.6.2014 23:23, Randy Dunlap napsal(a):
>> On 06/05/14 08:56, Michal Marek wrote:
>>> On Wed, Jun 04, 2014 at 03:12:33PM +0200, Michal Marek wrote:
>>>> On 2014-06-04 11:43, Michal Marek wrote:
>>>>> On 2014-06-04 11:03, Richard Weinberger wrote:
>>>>>> To reproduce run:
>>>>>> make defconfig ARCH=um O=/mnt/o && make linux ARCH=um O=/mnt/
>>>>>>
>>>>>> If there is anything in UML which needs fixing, please tell. :-)
>>>>>
>>>>> I'll have a look, thanks for the report.
>>>>
>>>> Findings so far: For some reason, syscalls_32.h is generated in the
>>>> source tree (which is wrong) and syscalls_64.h is not generated at all.
>>>> Looking further.
>>>
>>> Can you try the below patch? The same pattern is used in the rules for
>>> tools/ and tools/% in the main Makefile, need to look into that as well.
>>> But UML should work now.
>>>
>>> Michal
>>>
>>> From d4bc590f8716f7dde6b7bca319097ac30a8cb0b4 Mon Sep 17 00:00:00 2001
>>> From: Michal Marek <mmarek@suse.cz>
>>> Date: Thu, 5 Jun 2014 17:44:44 +0200
>>> Subject: [PATCH] um: Fix for relative objtree when generating x86 headers
>>>
>>> In an O= build, rely on the generated Makefile to call the main Makefile
>>> properly. When building in the source tree, we do not need to specify
>>> the -C and O= either. This fixes the problem when $(objtree) is a
>>> relative path and the -C changes the directory.
>>>
>>> Reported-by: Richard Weinberger <richard.weinberger@gmail.com>
>>> Signed-off-by: Michal Marek <mmarek@suse.cz>
>>> ---
>>>  arch/um/Makefile | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/arch/um/Makefile b/arch/um/Makefile
>>> index 36e658a..e4b1a96 100644
>>> --- a/arch/um/Makefile
>>> +++ b/arch/um/Makefile
>>> @@ -111,8 +111,7 @@ endef
>>>  KBUILD_KCONFIG := $(HOST_DIR)/um/Kconfig
>>>  
>>>  archheaders:
>>> -	$(Q)$(MAKE) -C '$(srctree)' KBUILD_SRC= \
>>> -		ARCH=$(HEADER_ARCH) O='$(objtree)' archheaders
>>> +	$(Q)$(MAKE) KBUILD_SRC= ARCH=$(HEADER_ARCH) archheaders
>>>  
>>>  archprepare: include/generated/user_constants.h
>>>  
>>>
>>
>> I still get this build error when building uml for i386:
>>
>>   CC      arch/x86/um/user-offsets.s
>> ../arch/x86/um/user-offsets.c:14:29: fatal error: asm/syscalls_32.h: No such file or directory
>> compilation terminated.
>> make[2]: *** [arch/x86/um/user-offsets.s] Error 1
> 
> Thanks for testing the patch. I cannot reproduce it though:
> 
>   make ARCH=um SUBARCH=i386 O=/dev/shm/li defconfig
>   make ARCH=um SUBARCH=i386 O=/dev/shm/li

That doesn't work for me either.  Must be a difference somewhere else.
I am using linux-next of 20140606 (latest that I know of) with only your
recent patch applied to it.

> works fine (at least it gets to the point when it starts compiling the
> actual kernel source). This is the previous kbuild/kbuild branch (commit
> 9da0763) with the above fix applied.
> 
> Also, you pointed out i386 -- Does it mean that the fix worked for you
> on x86_64?

Yes, it did work on x86_64 for some reason.


-- 
~Randy

  reply	other threads:[~2014-06-09 22:24 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-09 12:52 [PATCH v2 0/5] kbuild: Use relative paths if possible Michal Marek
2014-05-09 12:52 ` [PATCH v2 1/5] firmware: Simplify directory creation Michal Marek
2014-05-09 16:51   ` Sam Ravnborg
2014-05-14 20:53     ` Michal Marek
2014-05-09 12:52 ` [PATCH v2 2/5] firmware: Use $(quote) in the Makefile Michal Marek
2014-05-09 12:52 ` [PATCH v2 3/5] kbuild: Use relative path for $(objtree) Michal Marek
2014-06-04  9:03   ` Richard Weinberger
2014-06-04  9:43     ` Michal Marek
2014-06-04 13:12       ` Michal Marek
2014-06-05 15:56         ` Michal Marek
2014-06-05 15:56           ` Michal Marek
2014-06-09 21:12           ` Michal Marek
2014-06-09 21:23           ` Randy Dunlap
2014-06-09 22:14             ` Michal Marek
2014-06-09 22:24               ` Randy Dunlap [this message]
2014-06-09 22:39                 ` Michal Marek
2014-06-09 23:47                   ` Randy Dunlap
2014-06-10  9:02                     ` Michal Marek
2014-06-10 14:09                       ` Randy Dunlap
2014-06-10 14:30                         ` Michal Marek
2014-06-10  7:40           ` Geert Uytterhoeven
2014-06-10  8:17             ` Michal Marek
2017-10-16 10:26           ` Geert Uytterhoeven
2017-10-16 10:28             ` Geert Uytterhoeven
2017-10-25 12:21             ` Masahiro Yamada
2014-05-09 12:52 ` [PATCH v2 4/5] kbuild: Use relative path when building in the source tree Michal Marek
2014-05-09 12:52 ` [PATCH v2 5/5] kbuild: Use relative path when building in a subdir of " Michal Marek

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=5396340B.6060804@infradead.org \
    --to=rdunlap@infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=richard.weinberger@gmail.com \
    --cc=sam@ravnborg.org \
    /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.