On Tue, Nov 3, 2015 at 8:04 AM, markus at trippelsdorf dot de
<[email protected]> wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=19197
>
> Markus Trippelsdorf <markus at trippelsdorf dot de> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |luto at kernel dot org
>
> --- Comment #8 from Markus Trippelsdorf <markus at trippelsdorf dot de> ---
> Andy, would it be possible to just get rid of LDFLAGS for the x86 kernel?
>
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 747860c696e1..b786a2ce58b5 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -169,8 +169,6 @@ avx2_instr :=$(call as-instr,vpbroadcastb
> %xmm0$(comma)%ymm1,-DCONFIG_AS_AVX2=1)
> KBUILD_AFLAGS += $(asinstr) $(avx_instr) $(avx2_instr)
> KBUILD_CFLAGS += $(asinstr) $(avx_instr) $(avx2_instr)
>
> -LDFLAGS := -m elf_$(UTS_MACHINE)
> -
> # Speed up the build
> KBUILD_CFLAGS += -pipe
> # Workaround for a gcc prelease that unfortunately was shipped in a suse
> release
>
> Currently it calls "ld -m elf_x86_64" and then uses OUTPUT_ARCH(i386) in
> linker scripts several times during the build.
>
I don't know the history here. hpa? Andi?
Presumably we could strip the problematic -m argument from just the
32-bit things is we care.
--Andy
> I don't know the history here. hpa? Andi?
>
> Presumably we could strip the problematic -m argument from just the
> 32-bit things is we care.
I don't think it was intentional or there from the beginning, probably a bug
added somewhere on the way. Removing it seems fine.
-Andi
--
[email protected] -- Speaking for myself only.