2007-10-10 19:15:47

by Matthew Wilcox

[permalink] [raw]
Subject: [[email protected]: Re: [parisc-linux] parisc arch makefile clean-up needed [Was: cleaning up "make headers_install" for various architectures]]


Sam mipslet 'parisc-linux' in the first mail ... so i replied to the
second mail ... without checking l-k was still cc'd.

----- Forwarded message from Matthew Wilcox <[email protected]> -----

From: Matthew Wilcox <[email protected]>
To: Sam Ravnborg <[email protected]>
Cc: [email protected]
Subject: Re: [parisc-linux] parisc arch makefile clean-up needed [Was:
cleaning up "make headers_install" for various architectures]

On Wed, Oct 10, 2007 at 08:42:25PM +0200, Sam Ravnborg wrote:
> parisc arch Makefile needs some love and care...
>
> The logic selecting CROSS_COMPILE seems fishy and wrong -
> the error reported by rday is obvious in this respect.

He doesn't have a compiler installed that can target parisc. It doesn't
seem obvious to me that this should work.

> FINAL_LD is unused - kill it.

OK.

> Building with oldpalo has been broken for a loong time - time to kill it?
> Hint - the "cd ../palo" is not working as expected.
> And use of TOPDIR is deprecated.

OK, killed. I don't think anyone still uses that.

> The libs-y assignment should learn from the other architectures how to
> get the gcc lib filename:
> $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)

Actually, this looks utterly unstandardised:

arch/cris/Makefile:LIBGCC = $(shell $(CC) $(CFLAGS) -print-file-name=libgcc.a)
arch/h8300/Makefile:LIBGCC := $(shell $(CROSS-COMPILE)$(CC) $(CFLAGS) -print-libgcc-file-name)
arch/m32r/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
arch/parisc/Makefile:libs-y += arch/parisc/lib/ `$(CC) -print-libgcc-file-name`
arch/sh64/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
arch/sh/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)

How about we set it in the main Makefile, or one of the ones in
scripts/? That way we don't have to learn why $(shell $(CC) $(CFLAGS)
-print-libgcc-file-name) is superior to `$(CC) -print-libgcc-file-name`

>
> And this snippet is also wrong:
> PALO := $(shell if which palo; then : ; \
> elif [ -x /sbin/palo ]; then echo /sbin/palo; \
> fi)
>
> palo: vmlinux
> @if [ -x $PALO ]; then \
>
>
> Make does not export variables so $PALO is not the same as $(PALO).
> The latter should be used.

Huh. Looks like the sense of the test is reversed too. That should
probably be:

@if [ ! -x $(PALO) ]; then \

> I did not supply a patch because I do not fully understand the
> logic behind setting CROSS_COMPILE and 64BIT or not.
> But I will be happy to review a patch to fix the issues in the
> parisc Makefile.

One issue is that we don't have native 64-bit userspace on parisc.
And we don't have a toolchain that you can pass -m32/-m64 to; you have
to explicitly build a hppa64-linux-gnu toolchain. Another thing we try
and make user-friendly is that if you're building the parisc kernel on
a non-parisc machine, you need to use a cross-compiler, so we autodetect
that case for you.

--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
_______________________________________________
parisc-linux mailing list
[email protected]
http://lists.parisc-linux.org/mailman/listinfo/parisc-linux

----- End forwarded message -----

--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."


2007-10-10 19:49:24

by Robert P. J. Day

[permalink] [raw]
Subject: Re: [[email protected]: Re: [parisc-linux] parisc arch makefile clean-up needed [Was: cleaning up "make headers_install" for various architectures]]

On Wed, 10 Oct 2007, Matthew Wilcox wrote:

>
> Sam mipslet 'parisc-linux' in the first mail ... so i replied to the
> second mail ... without checking l-k was still cc'd.
>
> ----- Forwarded message from Matthew Wilcox <[email protected]> -----
>
> From: Matthew Wilcox <[email protected]>
> To: Sam Ravnborg <[email protected]>
> Cc: [email protected]
> Subject: Re: [parisc-linux] parisc arch makefile clean-up needed [Was:
> cleaning up "make headers_install" for various architectures]
>
> On Wed, Oct 10, 2007 at 08:42:25PM +0200, Sam Ravnborg wrote:
> > parisc arch Makefile needs some love and care...
> >
> > The logic selecting CROSS_COMPILE seems fishy and wrong -
> > the error reported by rday is obvious in this respect.
>
> He doesn't have a compiler installed that can target parisc. It
> doesn't seem obvious to me that this should work.

are you claiming that installing arch-specific kernel headers should,
in fact, require an appropriate cross compiler? i wouldn't have
thought so, but i'm willing to be corrected.

rday

--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

2007-10-10 19:52:47

by Sam Ravnborg

[permalink] [raw]
Subject: Re: parisc arch makefile clean-up needed [Was: cleaning up "make headers_install" for various architectures]

> On Wed, Oct 10, 2007 at 08:42:25PM +0200, Sam Ravnborg wrote:
> > parisc arch Makefile needs some love and care...
> >
> > The logic selecting CROSS_COMPILE seems fishy and wrong -
> > the error reported by rday is obvious in this respect.
>
> He doesn't have a compiler installed that can target parisc. It doesn't
> seem obvious to me that this should work.

We have at least the header_install target where it makes sense
to continue with a gcc that is not for the architecture being build.

So plain gcc (aka no CROSS_COMPILE) should be the fallback
solution. This fallback is anyway what most architectures use.


> > The libs-y assignment should learn from the other architectures how to
> > get the gcc lib filename:
> > $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
>
> Actually, this looks utterly unstandardised:
>
> arch/cris/Makefile:LIBGCC = $(shell $(CC) $(CFLAGS) -print-file-name=libgcc.a)
> arch/h8300/Makefile:LIBGCC := $(shell $(CROSS-COMPILE)$(CC) $(CFLAGS) -print-libgcc-file-name)
> arch/m32r/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
> arch/parisc/Makefile:libs-y += arch/parisc/lib/ `$(CC) -print-libgcc-file-name`
> arch/sh64/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
> arch/sh/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
> arch/xtensa/Makefile:LIBGCC := $(shell $(CC) $(CFLAGS) -print-libgcc-file-name)
>
> How about we set it in the main Makefile, or one of the ones in
> scripts/? That way we don't have to learn why $(shell $(CC) $(CFLAGS)
> -print-libgcc-file-name) is superior to `$(CC) -print-libgcc-file-name`

cris lacks a major rehaul - planned in this merge window. Will sync it when done.
h8300 should not use CROSS_COMPILE - a bit confused here.

And the reason why $(shell ) is preferred over backticks is simple.
We almost never use backticks in the kernel Makefile since the $(shell )
syntax is more obvious and I like it this way.

Sam