gcc fatal error: '-fuse-linker-plugin', but liblto_plug

[DiTBho]

I'm trying to build a custom toolchain, more or less, except this one

Code: [Select]

elf-gcc: fatal error: '-fuse-linker-plugin', but liblto_plugin.so not found
does anyone by any chance know what is this error related to? and how to workaround it?

[DiTBho]

gcc-v9.3.0
baremetal

[DiTBho]

it appears that one of these flags is causing the error

Code: [Select]

gcc-elf \
         -fleading-underscore \
         -Wa,--register-prefix-optional \
         -fno-reorder-functions \
         -DELF_TOOLCHAIN \
         -fomit-frame-pointer \
         -fno-common \
         -Wall \
         -Werror=undef \
         -Werror=missing-prototypes \
         -Werror=strict-prototypes \
         -Werror=implicit-function-declaration \
         -Werror=format \
         -Werror=redundant-decls \
         -Werror=format-extra-args \
         -Werror=old-style-definition \
         -Werror=type-limits \
         -DWITH_AES=1 \
         -DWITH_CLI=1 \
         ....

interesting 

[grumpydoc]

Previously (though briefly) discussed:

https://www.eevblog.com/forum/microcontrollers/arm-none-eabi-g-error-fuse-linker-plugin-but-liblto_plugin-so-not-found/

Possible gcc installation problem?

[DiTBho]

Possible gcc installation problem?

I am making a custom minimal toolchain builder

Code: [Select]

C3750 /projects/devchain-baremetal-2023/mybuilder# ./mybuild info all
BC success: m6811-elf, binutils v2.23, gcc v3.3.6-s12x, mini mode
BC success: m68k-elf, binutils v2.34, gcc v9.3.0, mini mode
BC success: m88k-coff, binutils v2.16.1, gcc v3.1.1, mini mode
BC success: mips-elf, binutils v2.24, gcc v9.3.0, mini mode
BC success: mips64-elf, binutils v2.24, gcc v9.3.0, mini mode
BC success: powerpc-elf, binutils v2.24, gcc v9.3.0, mini mode
BC success: powerpc-eabi, binutils v2.24, gcc v9.3.0, mini mode
BC success: arm-eabi, binutils v2.24, gcc v9.3.0, mini mode
BC success: sh2-elf, binutils v2.24, gcc v9.3.0, mini mode
BC success: riscv32-elf, binutils v2.39, gcc v9.3.0, mini mode
BC success: hppa-unknown-linux-gnu, binutils v2.24, gcc v9.3.0, mini mode

mini mode means that only these files are installed

Code: [Select]

/usr/idp/bin/$arch-addr2line
/usr/idp/bin/$arch-ar
/usr/idp/bin/$arch-as
/usr/idp/bin/$arch-cc1
/usr/idp/bin/$arch-cpp
/usr/idp/bin/$arch-gcc
/usr/idp/bin/$arch-gcov
/usr/idp/bin/$arch-ld
/usr/idp/bin/$arch-nm
/usr/idp/bin/$arch-objcopy
/usr/idp/bin/$arch-objdump
/usr/idp/bin/$arch-protoize
/usr/idp/bin/$arch-ranlib
/usr/idp/bin/$arch-readelf
/usr/idp/bin/$arch-size
/usr/idp/bin/$arch-strings
/usr/idp/bin/$arch-strip
/usr/idp/bin/$arch-unprotoize

The binutils and gcc sources have been hacked and patched to have cc1 in the wished place.

All the minimal (gcc -S, gcc -c, link with minimal link script) test-benches pass

Code: [Select]

C3750 /projects/devchain-baremetal-2023/mybuilder test all
testing m6811-elf-gcc ... success
testing m68k-elf-gcc ... success
testing m88k-coff-gcc ... success
testing mips-elf-gcc ... success
testing mips64-elf-gcc ... success
testing powerpc-elf-gcc ... success
testing powerpc-eabi-gcc ... success
testing arm-eabi-gcc ... success
testing sh2-elf-gcc ... success
testing riscv32-elf-gcc ... success
testing hppa-unknown-linux-gnu-gcc ... success

Essentially this stuff is able to compile a simple bootloader written in C, but not a complex project like an Operating System.

I still have to understand the above error, because, essentially, -fuse-linker-plugin "should be" no longer necessary.

These differences are subtle. First, understand what -flto actually does. It essentially creates an output that can be optimized later (at "link-time").

What -fwhole-program does is assumes "that the current compilation unit represents the whole program being compiled" whether or not that is actually the case. Therefore, GCC will assume that it knows all of the places that call a particular function. As it says, it might use more aggressive inter-procedural optimizers. I'll explain that in a bit.

Lastly, what -fuse-linker-plugin does is actually perform the optimizations at link time that would normally be done as each compilation unit is performed. So, this one is designed to pair with -flto because -flto means save enough information to do optimizations later and -fuse-linker-plugin means actually do those optimizations.

So, where do they differ? Well, as GCC doc suggests, there is no advantage in principle of using -fwhole-program because that option assumes something that you then have to ensure is true. To break it, simply define a function in one .cpp file and use it in another. You will get a linker error.

Is there any advantage to -fwhole-program? Well, if you only have one compilation unit then you can use it, but honestly, it won't be any better. I was able to get different sized executables by using equivalent programs, but when checking the actual generated machine code, they were identical. In fact, the only differences that I saw were that line numbers with debugging information were different.

(from here, stackoverflow.com, questions#15606993)

[DiTBho]

Passing this flag to gcc seems to fix the problem

Code: [Select]

-fno-use-linker-plugin

But I feel I'd better re-configure Binutils and Gcc to disable LTO

"This option [-fuse-linker-plugin] is enabled by default when LTO support in GCC is enabled and GCC was configured for use with a linker supporting plugins (GNU ld 2.21 or newer or gold)."

Code: [Select]

C3750 /projects/devchain-baremetal-2023/mybuilder show profile/gcc/9.3.0/configure.bootstrap
--without-newlib
--disable-multilib
--enable-languages=c
--without-header
--disable-shared
--disable-threads
--with-system-zlib
--enable-tls
--disable-libatomic
--disable-libmudflap
--disable-libssp
--disable-libquadmath
--disable-libgomp
--disable-nls
--disable-bootstrap

Dunno, I will try 

[DiTBho]

Code: [Select]

--enable-lto
--disable-lto
Enable support for link-time optimization (LTO). This is enabled by default, and may be disabled using --disable-lto.

--enable-linker-plugin-configure-flags=FLAGS
--enable-linker-plugin-flags=FLAGS
By default, linker plugins (such as the LTO plugin) are built for the host system architecture. For the case that the linker has a different (but run-time compatible) architecture, these flags can be specified to build plugins that are compatible to the linker. For example, if you are building GCC for a 64-bit x86_64 (‘x86_64-pc-linux-gnu’) host system, but have a 32-bit x86 GNU/Linux (‘i686-pc-linux-gnu’) linker executable (which is executable on the former system), you can configure GCC as follows for getting compatible linker plugins:

% srcdir/configure \
    --host=x86_64-pc-linux-gnu \
    --enable-linker-plugin-configure-flags=--host=i686-pc-linux-gnu \
    --enable-linker-plugin-flags='CC=gcc\ -m32\ -Wl,-rpath,[...]/i686-pc-linux-gnu/lib'
--with-plugin-ld=pathname
Enable an alternate linker to be used at link-time optimization (LTO) link time when -fuse-linker-plugin is enabled. This linker should have plugin support such as gold starting with version 2.20 or GNU ld starting with version 2.21. See -fuse-linker-plugin for details.
(from here, Gcc configure)

[DiTBho]

gcc
re-configured
re-compiled
now it works