[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1446844180.11597.13.camel@freescale.com>
Date: Fri, 6 Nov 2015 15:09:40 -0600
From: Scott Wood <scottwood@...escale.com>
To: Laurent Vivier <laurent@...ier.eu>
CC: <benh@...nel.crashing.org>, <paulus@...ba.org>,
<linuxppc-dev@...ts.ozlabs.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] powerpc: allow cross-compilation of ppc64 kernel
On Thu, 2015-11-05 at 12:47 +0100, Laurent Vivier wrote:
> When I try to cross compile a ppc64 kernel, it generally
> fails on the VDSO stage. This is true for powerpc64 cross-
> compiler, but also when I try to build a ppc64le kernel
> on a ppc64 host.
>
> VDSO64L fails:
>
> VDSO64L arch/powerpc/kernel/vdso64/vdso64.so.dbg
> /usr/bin/powerpc64-linux-gnu-ld: arch/powerpc/kernel/vdso64/sigtramp.o:
> file class ELFCLASS64 incompatible with ELFCLASS32
> /usr/bin/powerpc64-linux-gnu-ld: final link failed: File in wrong format
>
> This fails because gcc calls "collect2" with
> "--oformat elf32-powerpcle" with ppc64 objects, without the
> "--oformat" ld works well because it use the format of the
> first object as output format.
>
> As this case is correctly managed to build the other kernel
> objects, this patch replaces $(GCC) by $(LD) to generate the
> VDSO objects.
I cross-compile ppc64 kernels and have not seen this problem. I do need to
pass in -m64 as part of $(CC) if it's not the toolchain default, which is not
nice, but the proper fix for that is to add -m64 in the makefiles -- and if I
don't it fails way before VDSO.
Why is GCC building ppc64 object files but telling the linker --oformat elf32-
powerpcle? Are different options somehow being passed to GCC in one case
versus the other?
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists