linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: Masahiro Yamada <masahiroy@kernel.org>
Cc: "James E . J . Bottomley" <James.Bottomley@hansenpartnership.com>,
	linux-parisc@vger.kernel.org,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] parisc: suppress error messages for 'make clean'
Date: Sun, 10 May 2020 22:28:24 +0200	[thread overview]
Message-ID: <11e05a6d-e4bd-e381-7015-2d52e8fdef39@gmx.de> (raw)
In-Reply-To: <CAK7LNAR+jEzqqFJbCzfEbdnt-H4ZRpfLFA30ODfhhH=QXSk5nQ@mail.gmail.com>

On 10.05.20 03:19, Masahiro Yamada wrote:
> Hi Helge,
>
> On Sun, May 10, 2020 at 2:39 AM Helge Deller <deller@gmx.de> wrote:
>>
>> * Masahiro Yamada <masahiroy@kernel.org>:
>>> Hi Helge,
>>>
>>> On Sat, May 9, 2020 at 6:46 AM Helge Deller <deller@gmx.de> wrote:
>>>>
>>>> * Masahiro Yamada <masahiroy@kernel.org>:
>>>>> On Sat, Apr 25, 2020 at 2:47 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>>>>>>
>>>>>> 'make ARCH=parisc clean' emits a tons of error messages as follows:
>>>>>>
>>>>>>   $ make ARCH=parisc clean
>>>>>>   gcc: error: unrecognized command line option '-mno-space-regs'
>>>>>>   gcc: error: unrecognized command line option '-mfast-indirect-calls'; did you mean '-mforce-indirect-call'?
>>>>>>   gcc: error: unrecognized command line option '-mdisable-fpregs'
>>>>>>   gcc: error: missing argument to '-Wframe-larger-than='
>>>>>>   gcc: error: unrecognized command line option '-mno-space-regs'
>>>>>>   gcc: error: unrecognized command line option '-mfast-indirect-calls'; did you mean '-mforce-indirect-call'?
>>>>>>   gcc: error: unrecognized command line option '-mdisable-fpregs'
>>>>>>   gcc: error: missing argument to '-Wframe-larger-than='
>>>>>>     ...
>>>>>>
>>>>>> You can supporess them except '-Wframe-larger-than' by setting correct
>>>>>> CROSS_COMPILE=, but we should not require any compiler for cleaning.
>>>>>>
>>>>>> This $(shell ...) is evaluated so many times because LIBGCC is exported.
>>>>>> Use the ':=' operator to evaluate it just once, and sink the stderr.
>>>>>>
>>>>>
>>>>> Applied to linux-kbuild.
>>>>
>>>> That patch breaks then building the boot loader/compressor:
>>>> ...
>>>>   hppa-linux-gnu-ld    -X -e startup --as-needed -T arch/parisc/boot/compressed/vmlinux.lds arch/parisc/boot/compressed/head.o arch/parisc/boot/compressed/real2.o arch/parisc/boot/compressed/firmware.o arch/parisc/boot/compressed/misc.o arch/parisc/boot/compressed/piggy.o -o arch/parisc/boot/compressed/vmlinux
>>>> hppa-linux-gnu-ld: arch/parisc/boot/compressed/misc.o: in function `dec_vli':
>>>> (.text+0x104): undefined reference to `__ashldi3'
>>>> hppa-linux-gnu-ld: arch/parisc/boot/compressed/misc.o: in function `lzma_len':
>>>> (.text+0x2b0): undefined reference to `$$mulI'
>>>> hppa-linux-gnu-ld: (.text+0x344): undefined reference to `$$mulI'
>>>> hppa-linux-gnu-ld: (.text+0x3f8): undefined reference to `$$mulI'
>>>>
>>>>
>>>> The patch below works, but I wonder if it's possible to avoid
>>>> to examine LIBGCC twice....?
>>>>
>>>> Helge
>>>
>>>
>>> Sorry for the breakage.
>>>
>>> How about moving LIBGCC below ?
>>
>> Good idea.
>> The patch below does work for me.
>> We do not need $KBUILD_CFLAGS to get the libgcc.a filename,
>
>
> I not not sure about this change.
> Generally speaking, the path to libgcc.a is affected
> by compiler flags, especially, bit size flags,
> endian flags, etc.
>
> For example, my distro gcc is biarch for i386/x86_64.
>
> $ gcc -print-libgcc-file-name
> /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
> $ gcc -m64 -print-libgcc-file-name
> /usr/lib/gcc/x86_64-linux-gnu/9/libgcc.a
> $ gcc -m32 -print-libgcc-file-name
> /usr/lib/gcc/x86_64-linux-gnu/9/32/libgcc.a
>
> One real example in Linux is arch/arc/Makefile.
> ARC supports both big endian and little endian.
>
> If you drop cflags-y from line 59
> of arch/arc/Makefile, vmlinux fails to link
> due to endian mismatch.
>
>
> I am not familiar with parisc.
> Also, as it turned out,
> this change is not so trivial.
>
> I think the best approach is to leave this up to you
> since you are the parisc maintainer.

Yes, I knew about the possible biarch options.
On parisc that's not relevant yet.


> I will drop this patch from my kbuild tree,
> then you will apply what you think is best
> to your tree.
>
> What do you think?

Sure, I'll take it through the parisc tree.

Thanks!
Helge



>> so we do not need to pipe the output to /dev/null either.
>> Can you try if that works, and if yes, can you apply it?
>>
>> Helge
>>
>>
>> diff --git a/arch/parisc/Makefile b/arch/parisc/Makefile
>> index 628cd8bb7ad8..fadbbd010337 100644
>> --- a/arch/parisc/Makefile
>> +++ b/arch/parisc/Makefile
>> @@ -21,8 +21,6 @@ KBUILD_IMAGE := vmlinuz
>>
>>  NM             = sh $(srctree)/arch/parisc/nm
>>  CHECKFLAGS     += -D__hppa__=1
>> -LIBGCC         = $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
>> -export LIBGCC
>>
>>  ifdef CONFIG_64BIT
>>  UTS_MACHINE    := parisc64
>> @@ -110,6 +108,8 @@ cflags-$(CONFIG_PA8X00)             += -march=2.0 -mschedule=8000
>>  head-y                 := arch/parisc/kernel/head.o
>>
>>  KBUILD_CFLAGS  += $(cflags-y)
>> +LIBGCC         := $(shell $(CC) -print-libgcc-file-name)
>> +export LIBGCC
>>
>>  kernel-y                       := mm/ kernel/ math-emu/
>>
>
>


  reply	other threads:[~2020-05-10 20:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-25  5:46 [PATCH] parisc: suppress error messages for 'make clean' Masahiro Yamada
2020-05-01  5:35 ` Masahiro Yamada
2020-05-08 21:46   ` Helge Deller
2020-05-09  8:16     ` Masahiro Yamada
2020-05-09 17:39       ` Helge Deller
2020-05-10  1:19         ` Masahiro Yamada
2020-05-10 20:28           ` Helge Deller [this message]
2020-06-13 19:36             ` Rolf Eike Beer
2020-06-13 22:48               ` Helge Deller

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=11e05a6d-e4bd-e381-7015-2d52e8fdef39@gmx.de \
    --to=deller@gmx.de \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=masahiroy@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).