http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56893
Bug #: 56893
Summary: gcc-ar-4.7: Cannot find liblto_plugin.so on Darwin
Classification: Unclassified
Product: gcc
Version: lto
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: plugins
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: datas...@yahoo.com
Created attachment 29841
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29841
Makefile for Mac
Using gcc 4.7.2 on the Mac I appear to be running into LTO problems as well:
$ /usr/gcc-4.7.2/bin/gcc-ar-4.7
/usr/gcc-4.7.2/bin/gcc-ar-4.7: Cannot find plugin
/usr/gcc-4.7.2/libexec/gcc//x86_64-apple-darwin12.2.0/4.7.2/liblto_plugin.so
$ /usr/gcc-4.7.2/bin/gcc-ranlib-4.7
/usr/gcc-4.7.2/bin/gcc-ranlib-4.7: Cannot find plugin
/usr/gcc-4.7.2/libexec/gcc//x86_64-apple-darwin12.2.0/4.7.2/liblto_plugin.so
$ /usr/gcc-4.7.2/bin/gcc-nm-4.7
/usr/gcc-4.7.2/bin/gcc-nm-4.7: Cannot find plugin
/usr/gcc-4.7.2/libexec/gcc//x86_64-apple-darwin12.2.0/4.7.2/liblto_plugin.so
That is a bummer, one of the charms of 4.7 is supposed to be link time
optimisation. For what it is worth the patch mentioned in Bug 53126 – gcc-4.7.0
error "gcc-ar: Cannot find plugin" was already applied to the source code. But
the fact that on the mac gcc-ar is looking for an '.so' instead of a '.dylib'
seems odd. It would seem that
/usr/gcc-4.7.2/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/lto-wrapper needs to
be used because this symlink seems to fix it:
sudo ln -s
/usr/gcc-4.7.2/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/lto-wrapper
/usr/gcc-4.7.2/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/liblto_plugin.so
