Question about ld tests requiring plugins support

[Bin.Cheng]

Hi,
I ran into ld/lto testing failures of my arm/aarch64 toolchain. The
command and error message is like below.
Executing on host: sh -c
{/home/binche01/work/oban-work/build-aarch64-none-elf/obj/binutils/ld/../binutils/ar
-rc tmpdir/liblto-12.a tmpdir/lto-12c.o 2>&1} /dev/null ld.tmp
(timeout = 1500)
spawn [open ...]
BFD: tmpdir/lto-12c.o: plugin needed to handle lto object
BFD: tmpdir/lto-12c.o: plugin needed to handle lto object

I suppose it's necessary to specify "--plugin .../liblto_plugin.so",
but not sure how to do it. Do I need to add this option in dejagnu
stuff, or it can be done automatically by configuring binutils with
some options?

Thanks,
bin

[Nicholas Clifton]

Hi Bin,

Post by Bin.Cheng
I ran into ld/lto testing failures of my arm/aarch64 toolchain. The
BFD: tmpdir/lto-12c.o: plugin needed to handle lto object

Try recreating your toolchain. This time add "--enable-plugins" to the
configure command line.

Cheers
Nick

[Bin.Cheng]

Post by Nicholas Clifton
Hi Bin,

Post by Bin.Cheng
I ran into ld/lto testing failures of my arm/aarch64 toolchain. The
BFD: tmpdir/lto-12c.o: plugin needed to handle lto object

Try recreating your toolchain. This time add "--enable-plugins" to the
configure command line.

Hi Nick, thanks for helping. I tried with that both for gcc and
binutils, but no luck.

After looking into lto.exp, I found below code snippet.

set plugin_names {
liblto_plugin.so
liblto_plugin-0.dll
cyglto_plugin-0.dll
}
set plug_opt ""
foreach plug $plugin_names {
set plug_so [run_host_cmd $CC "--print-file-name $plug"]
if { $plug_so ne $plug } then {
set plug_opt "--plugin $plug_so"
break
}
}

For my toolchain, the check always output the file name, rather than
the full path of the plugins.
/home/binche01/work/target-aarch64-none-elf/bin/aarch64-none-elf-gcc
-B/home/binche01/work/build-aarch64-none-elf/obj/binutils/ld/tmpdir/ld/
-L/home/binche01/work/target-aarch64-none-elf/aarch64-none-elf/lib
--print-file-name liblto_plugin.so
liblto_plugin.so

Even file "liblto_plugin.so" does exist in the installation place:
.../target-aarch64-none-elf/libexec/gcc/aarch64-none-elf/5.0.0/liblto_plugin.so

That's why "--plugin ...." is set to empty string.

Interesting thing is gcc manually says that:

-print-file-name=libraryPrint the full absolute name of the library
file library that would be used when linking--and don't do anything
else. With this option, GCC does not compile or link anything; it just
prints the file name.
Thanks,
bin

Post by Nicholas Clifton
Cheers
Nick

[Bin.Cheng]

Post by Bin.Cheng

Post by Nicholas Clifton
Hi Bin,

Post by Bin.Cheng
I ran into ld/lto testing failures of my arm/aarch64 toolchain. The
BFD: tmpdir/lto-12c.o: plugin needed to handle lto object

Try recreating your toolchain. This time add "--enable-plugins" to the
configure command line.

Hi Nick, thanks for helping. I tried with that both for gcc and
binutils, but no luck.
After looking into lto.exp, I found below code snippet.
set plugin_names {
liblto_plugin.so
liblto_plugin-0.dll
cyglto_plugin-0.dll
}
set plug_opt ""
foreach plug $plugin_names {
set plug_so [run_host_cmd $CC "--print-file-name $plug"]
if { $plug_so ne $plug } then {
set plug_opt "--plugin $plug_so"
break
}
}
For my toolchain, the check always output the file name, rather than
the full path of the plugins.
/home/binche01/work/target-aarch64-none-elf/bin/aarch64-none-elf-gcc
-B/home/binche01/work/build-aarch64-none-elf/obj/binutils/ld/tmpdir/ld/
-L/home/binche01/work/target-aarch64-none-elf/aarch64-none-elf/lib
--print-file-name liblto_plugin.so
liblto_plugin.so
.../target-aarch64-none-elf/libexec/gcc/aarch64-none-elf/5.0.0/liblto_plugin.so
That's why "--plugin ...." is set to empty string.
-print-file-name=libraryPrint the full absolute name of the library
file library that would be used when linking--and don't do anything
else. With this option, GCC does not compile or link anything; it just
prints the file name.

Most likely I configured my GCC in an inappropriate approach.

Thanks,
bin

Post by Bin.Cheng

Post by Nicholas Clifton
Cheers
Nick