"plugin needed to handle lto object"

[staalmannen]

I have followed the instructions under Documentation/lto-build and I use/have packaged a binutils from the hjl branch

https://aur.archlinux.org/packages/binutils-hjl-git/

Trying to build branch lto-4.0 fails with ld giving the error message
"plugin needed to handle lto object"

I run "make AR=gcc-ar NM=gcc-nm" but this does not seem to help.

Any other ideas what I have to change? Do I need to re-build GCC with the new binutils?
stock GCC should be built with --enable-plugin and --enable-lto
https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/gcc-multilib

Should I explicitly give an absolute path to the plugin in CFLAGS or something?

[andikleen]

Is your binutils built with --enable-plugins ?

[staalmannen]

I built binutils-hjl-git with --enable-lto and --enable-plugins and replaced the system version with it (so the ld path is /usr/bin/ld)

Testing binutils:
% ld --help | grep plugin
-plugin PLUGIN Load named plugin
-plugin-opt ARG Send arg to last-loaded plugin
ld: mål som stöds: elf64-x86-64 elf32-i386 elf32-iamcu elf32-x86-64 a.out-i386-linux pei-i386 pei-x86-64 elf64-l1om elf64-k1om elf64-little elf64-big elf32-little elf32-big plugin srec symbolsrec verilog tekhex binary ihex

Testing gcc:
% gcc -O2 hello.c -flto --verbose 2>&1 | grep collect2._plugin
zsh: no matches found: collect2._plugin

... so basically gcc can not use the hjl binutils as lto plugin?
Stock gcc on Arch is built with --enable-lto and --enable-plugin so it should work?

[staalmannen]

I think I solved it:
I set LD=gcc-ld (from scripts). This caused the LD tests in Makefile.lto to fail, so I patched them out

Now when I am compiling and if there is an error message I do see references to collect2, so I am fairly sure that it is running as an LTO build.

Will this "hack" cause any problems in the building of Linux?

On an unrelated note, I also apply the GCC architectures patch, which enables -march=native

https://github.com/graysky2/kernel_gcc_patch

(I am not interested in a portable kernel but one optimized for my machine, and I just run a localyesconfig)

Would there be any theoretical issues with higher gcc optimization levels and/or architecture-specific tuning while doing an LTO build?

[andikleen]

If LTO is active it should work. You can usually tell by just looking how long the final LD stage takes. With LTO it takes much longer.

LTO shouldn't have any problems with -march=native

[staalmannen]

Thanks. LTO is indeed active and everything runs well : ) (had to disable xen to build ). Is it a known issue that the gcc-ld wrapper fails the tests in Makefile.lto?

[andikleen]

The tests weren't really designed for gcc-ld, but I can add some hack.

What's the problem with Xen?