FS#43367 - [binutils] -flto doesn't work
Attached to Project:
Arch Linux
Opened by Juan Francisco Cantero Hurtado (juanfra) - Wednesday, 07 January 2015, 14:51 GMT
Last edited by Allan McRae (Allan) - Sunday, 03 May 2015, 11:41 GMT
Opened by Juan Francisco Cantero Hurtado (juanfra) - Wednesday, 07 January 2015, 14:51 GMT
Last edited by Allan McRae (Allan) - Sunday, 03 May 2015, 11:41 GMT
|
Details
Description:
When I build qemu with these CFLAGS: -Ofast -mtune=native -march=native -fuse-ld=gold -flto -fwhole-program i see a bunch of these warnings: BFD: libfdt/fdt.o: plugin needed to handle lto object I also tested without "fuse-ld" or with "fuse-linker-plugin" but I always see the same warnings. Maybe the PKGBUILD of gcc requires the option "--with-plugin-ld=ld.gold"? Additional info: * gcc 4.9.2-2 Steps to reproduce: Download the files to build the qemu package, add the CFLAGS and compile the package. I'm not asking for support to build qemu with crazy CFLAGS, the package is just an example to show the problem. |
This task depends upon
Closed by Allan McRae (Allan)
Sunday, 03 May 2015, 11:41 GMT
Reason for closing: Fixed
Additional comments about closing: gcc-5.1.0-2
Sunday, 03 May 2015, 11:41 GMT
Reason for closing: Fixed
Additional comments about closing: gcc-5.1.0-2
I'll try bisecting the git commit that introduced this issue when I get some free time...
commit b794fc1d1c3a3dfb65b74a36fe96c474fee65000
Author: Alan Modra <amodra@gmail.com>
Date: Mon Jul 28 22:18:25 2014 +0930
Warn for ar/nm/ranlib/ld on lto objects without plugin
$ ld --help | grep plugin
-plugin PLUGIN Load named plugin
-plugin-opt ARG Send arg to last-loaded plugin
ld: supported targets: elf64-x86-64 elf32-i386 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
$ gcc -O2 test.c -flto --verbose 2>&1 | grep collect2.*plugin
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/collect2 -plugin /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/liblto_plugin.so -plugin-opt=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper -plugin-opt=-fresolution=/tmp/ccPE9Ybk.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -flto --build-id --eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib/crt1.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib/crti.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/crtbegin.o -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2 -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../.. /tmp/ccBotdok.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/crtend.o /usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/../../../../lib/crtn.o
The "fix" is to use 'gcc-ar' in place of 'ar' (which invokes 'ar' with --plugin=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/liblto_plugin.so or similar).
Clang LTO seems happy to accept 'ar' libs without using 'ar --plugin=foo'.
ln -s /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/liblto_plugin.so /usr/lib/bfd-plugins/
This will be in gcc-5.1 when it moves from [testing].