Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 501178 - dev-lang/gnat-gcc-4.6.4: gnatmake always fails because it cannot find liblto_plugin.so
Summary: dev-lang/gnat-gcc-4.6.4: gnatmake always fails because it cannot find liblto_...
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: AMD64 Linux
: Normal normal
Assignee: No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it
URL:
Whiteboard:
Keywords:
: 515036 528854 536418 574678 (view as bug list)
Depends on: 574548
Blocks: lto
  Show dependency tree
 
Reported: 2014-02-13 12:18 UTC by Chris Brannon (RETIRED)
Modified: 2017-08-30 18:51 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Brannon (RETIRED) gentoo-dev 2014-02-13 12:18:37 UTC
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
Comment 1 Michael Mounteney 2014-08-24 03:25:08 UTC
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.
Comment 2 Erik 2014-12-27 03:47:29 UTC
I can confirm this bug. Tried without and with the lto USE-flag.
Comment 3 George Shapovalov (RETIRED) gentoo-dev 2016-02-10 15:56:35 UTC
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..
Comment 4 George Shapovalov (RETIRED) gentoo-dev 2016-02-10 15:58:25 UTC
*** Bug 515036 has been marked as a duplicate of this bug. ***
Comment 5 George Shapovalov (RETIRED) gentoo-dev 2016-02-10 15:59:25 UTC
*** Bug 528854 has been marked as a duplicate of this bug. ***
Comment 6 George Shapovalov (RETIRED) gentoo-dev 2016-02-10 16:00:57 UTC
*** Bug 536418 has been marked as a duplicate of this bug. ***
Comment 7 George Shapovalov (RETIRED) gentoo-dev 2016-02-10 16:10:36 UTC
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..
Comment 8 George Shapovalov (RETIRED) gentoo-dev 2016-02-12 09:56:54 UTC
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..
Comment 9 Toralf Förster gentoo-dev 2016-04-23 17:28:45 UTC
*** Bug 574678 has been marked as a duplicate of this bug. ***
Comment 10 Martin von Gagern 2016-11-01 18:55:53 UTC
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?
Comment 11 Pacho Ramos gentoo-dev 2017-08-30 18:51:35 UTC
removed