I see this behavior regardless of whether the lto USE flag is enabled. Script started on Thu 13 Feb 2014 04:08:13 AM PST chris@mushroom ~/tst $ gnatmake hello.adb gnatgcc -c hello.adb gnatgcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found compilation terminated. gnatmake: "hello.adb" compilation error chris@mushroom ~/tst $ exit exit Script done on Thu 13 Feb 2014 04:08:28 AM PST
Observed on x86 as well. Tried passing gnatmake -cargs -fno-lto -largs -fno-lto -margs -fno-lto but no change. Reverting to dev-lang/gnat-gcc-4.5.4 fixes it.
I can confirm this bug. Tried without and with the lto USE-flag.
Yes, looks like whoever added the lto flag in my absence has just added the basic logic - the use flag, but did not check that the liblto_plugin.so actually gets installed. This "fixed" the build, but now it makes it impossible to use gnat-gcc.. I'll try to fix this, hang on..
*** Bug 515036 has been marked as a duplicate of this bug. ***
*** Bug 528854 has been marked as a duplicate of this bug. ***
*** Bug 536418 has been marked as a duplicate of this bug. ***
Actually, it does get installed, just in the wrong location.. Gotta check if I can fix it in a "proper" way, if not, a dirty fix in eclass to move that lib personally to a proper place should do it..
Well, it seems more involved than just that: 1. gcc installs the so's under libexec too 2. just linking it to the "usual" place (for gnat) on a live system doesn't do anything 3. Worst of all - build scripts (gcc's) seem to simply ignore the --enable/disable-lto and build it all the time, thus breaking the result :( 4. At the same time, I cannot see any special handling of lto in the toolchain.. It seems that at this point I just have to bite the bullet and rewrite the gnatbuild.eclass to follow the new toolchain. I was planning to do this for quite a while, but postponing it, as it is quite a beast. Still, its been 10 years since I wrote the original gnatbuild.eclass which followed the toolchain of then. Tons of crust accumulated since, and my earlier attempts to issue a major update were failing with some weird errors (bunch of bugs to this effect here). And now its at the point where it isn't even working any more. So, looks like its a time to finally attempt the big overhaul.. I guess I'll open a new bug to track progress - as many other bugs would depend on that, not only this one..
*** Bug 574678 has been marked as a duplicate of this bug. ***
I have USE=-lto here, and according to strace gnatgcc will look for these paths: /usr/libexec/gnat-gcc/x86_64-pc-linux-gnu/4.6/gcc/x86_64-pc-linux-gnu/4.6.4/liblto_plugin.so /usr/libexec/gnat-gcc/x86_64-pc-linux-gnu/4.6/gcc/x86_64-pc-linux-gnu/4.6.4/liblto_plugin.so /usr/libexec/gnat-gcc/x86_64-pc-linux-gnu/4.6/gcc/x86_64-pc-linux-gnu/liblto_plugin.so /usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.6/gcc/x86_64-pc-linux-gnu/4.6.4/liblto_plugin.so /usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.6/gcc/x86_64-pc-linux-gnu/liblto_plugin.so /usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.6/../../../../x86_64-pc-linux-gnu/bin/x86_64-pc-linux-gnu/4.6.4/liblto_plugin.so /usr/lib64/gnat-gcc/x86_64-pc-linux-gnu/4.6/../../../../x86_64-pc-linux-gnu/bin/liblto_plugin.so The file's actual location appears to be /usr/libexec/gnat-gcc/x86_64-pc-linux-gnu/4.6/liblto_plugin.so So I tried working around the problem by creating a symlink like this: mkdir /usr/libexec/gnat-gcc/x86_64-pc-linux-gnu/4.6/gcc{,/x86_64-pc-linux-gnu} ln -s ../../liblto_plugin.so /usr/libexec/gnat-gcc/x86_64-pc-linux-gnu/4.6/gcc/x86_64-pc-linux-gnu/ And suddenly it looks as though I could compile topal successfully. Does this help?
removed
