On an up-to-date Fedora 32 x86_64 in a VirtualBox VM with 4 processors and 10 GB RAM, `gcc -flto=2` (or any number higher than 1) results in a linking failure, even with a trivial C program: ``` $ echo "int main() { return 0; }" > /tmp/main.c $ gcc /tmp/main.c -flto=2 lto-wrapper: fatal error: execvp: No such file or directory compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld return 1 exit status ``` Same issue with `g++`. `gcc -flto` or `gcc -flto=1` works fine. On Mageia Cauldron with GCC 9.3.0, `gcc -flto=2` works without problem (and it also works on Fedora 31). I've had other problems with LTO on Fedora 32+ with GCC 10 (works fine on Fedora 31 and earlier) as seem in bug 1812783, but I can't reproduce that bug for now due to this new bug I'm reporting.
Just tried this in mock F33 chroot (gcc in F32 is identical) and can't reproduce.
I can't reproduce it either using mock with fedora-32-x86_64, but it's still reproducible in my VM. I'm not sure what would cause this, it's a fairly simple VM which I only use for occasional packaging work (dnf distro-sync'd from F31).
It may make sense to look at rpm -qaV output at this point, to see if there are any files missing.
Created attachment 1678660 [details] Output of `rpm -qaV | sort` (In reply to Florian Weimer from comment #3) > It may make sense to look at rpm -qaV output at this point, to see if there > are any files missing. Thanks for the advice, I didn't know about this useful -V switch. Nothing seems to stand out in the output though (attached is the output of `sudo rpm -qaV | sort`).
Created attachment 1678661 [details] Output of `rpm -qa | sort` Here's the full `rpm -qa` for that VM. It's worth noting that I installed https://bodhi.fedoraproject.org/updates/FEDORA-2020-d927e07eb1 manually back when it was in testing, but I've checked and the packages I have installed have since been superseded by other validated updates.
Somebody reported the same issue within Fedora 33 container. I'm unable to reproduce it my virtual machine. I recommend the the people who suffer from this issue to help with the debugging: [test@fedora-33 tmp]$ gcc -flto=auto test.c [test@fedora-33 tmp]$ strace -fq -e execve -- gcc -flto=auto test.c 2>&1 | grep lto-wrapper [pid 986] execve("/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper", ["/usr/libexec/gcc/x86_64-redhat-l"..., "@/tmp/ccT3vKoI.lto_wrapper_args"], 0x7ffcf5988530 /* 25 vars */) = 0 [test@fedora-33 tmp]$ readlink -f /usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper /usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper [test@fedora-33 tmp]$ rpm -qf /usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper gcc-10.2.1-3.fc33.x86_64 [test@fedora-33 tmp]$ rpm -V gcc-10.2.1-3.fc33.x86_64 That list of the commands tracks what package provides the allegely missing lto-wrapper program. In my case it is provided by the gcc. The very same package the provides the gcc command. Please try it on your affected system and report the differences.
Hi Petr, I still have the same F32 VM locally (not updated since) and can reproduce the issue. Here's the requested output: [akien@localhost tmp]$ gcc -flto=auto main.c lto-wrapper: fatal error: execvp: No such file or directory compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status [akien@localhost tmp]$ strace -fq -e execve -- gcc -flto=auto main.c 2>&1 | grep lto-wrapper [pid 3047] execve("/usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper", ["/usr/libexec/gcc/x86_64-redhat-l"..., "@/tmp/ccMQnaLu.lto_wrapper_args"], 0x7ffdaf4f8070 /* 64 vars */) = 0 lto-wrapper: fatal error: execvp: No such file or directory /usr/bin/ld: error: lto-wrapper failed [akien@localhost tmp]$ readlink -f /usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper /usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper [akien@localhost tmp]$ rpm -qf /usr/libexec/gcc/x86_64-redhat-linux/10/lto-wrapper gcc-10.0.1-0.11.fc32.x86_64 [akien@localhost tmp]$ rpm -V gcc-10.0.1-0.11.fc32.x86_64
Same results after a `dnf update`. Now the lto-wrapper is provided by gcc-10.2.1-1.fc32.x86_64.
Can you please attach full strace -f -s 1024 -v dump? From the above seems execve actually succeeded...
Though, the message is not about being able to execve lto-wrapper, but about lto-wrapper not being able to exec other programs (most notably the gcc driver that should invoke lto1).
Created attachment 1715183 [details] Output of `strace -f -s 1024 -v -- gcc -flto=auto main.c 2>&1`
Do you have make installed?
Elliott Sales de Andrade posted an easy reproducer in fedora-devel: $ podman run --pull=always --rm -it registry.fedoraproject.org/fedora:rawhide # dnf install -y gcc # echo 'int main(void) { int class=0; return class; }' > sanitycheck.c # gcc -flto=auto sanitycheck.c -o sanitycheck lto-wrapper: fatal error: execvp: No such file or directory compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status The issue is simple: lto-wrapper calls /usr/bin/make, which is not installed.
Indeed, I did not have `make` installed. Installing it solves the issue. It should probably be added as a Requires for gcc.
It would be good if lto-wrapper included the file name that fails to execute in its error message.
*** Bug 1866012 has been marked as a duplicate of this bug. ***
Related upstream gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97524 Reproduced on a freshly installed f33: [ingvar@f33 ~]$ which make /usr/bin/which: no make in (/home/ingvar/.local/bin:/home/ingvar/bin:/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin) [ingvar@f33 ~]$ cat hello.c #include <stdio.h> int main(void) {printf ("Hello world\n"); return 0;} [ingvar@f33 ~]$ gcc -o hello hello.c && echo OK || echo FAILED OK [ingvar@f33 ~]$ gcc -flto=auto -o hello hello.c && echo OK || echo FAILED lto-wrapper: fatal error: execvp: Ingen slik fil eller filkatalog compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status FAILED [ingvar@f33 ~]$ sudo dnf -y install make [ingvar@f33 ~]$ gcc -flto=auto -o hello hello.c && echo OK || echo FAILED OK
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This seems to be fixed in update to gcc-10.2.1-8 From the specfile changelog: - add BuildRequires: make and Requires: make, the latter for -flto reasons So I guess this may be closed now. Ingvar
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.