g++: error: -fuse-linker-plugin is not supported in this configuration

[Hite, Christopher]

I can't get the linker plugin to work.
g++: error: -fuse-linker-plugin is not supported in this configuration

I build a userland binutils and gcc with dependencies. I've tried gold and bfd. Does anyone see anything obvoiusly wrong with this?

cd gcc-4.7.0
./configure --with-gmp=$INSTALLATION/gmp-4.3.2 --with-mpfr=$INSTALLATION/mpfr-2.4.2 --with-mpc=$INSTALLATION/mpc-0.8.2 --with-ppl=$INSTALLATION/ppl-0.11 \
--enable-cloog-backend=isl --with-cloog=$INSTALLATION/cloog-0.16.2 --prefix=$INSTALLATION/gcc-4.7.0 \
--enable-languages=c,c++ \
--enable-lto --with-libelf=$INSTALLATION/libelf-0.8.12 --enable-gold
make install

cd binutils-2.22
./configure --enable-gold --enable-plugins --enable-lto --with-gmp=$INSTALLATION/gmp-4.3.2 --with-mpfr=$INSTALLATION/mpfr-2.4.2 --with-mpc=$INSTALLATION/mpc-0.8.2 \
--with-ppl=$INSTALLATION/ppl-0.11 --enable-cloog-backend=isl --with-cloog=$INSTALLATION/cloog-0.16.2 --prefix=$INSTALLATION/binutils-2.22 \
--disable-werror
make all-gold


Do I have the order right? Someone mentioned an in-tree build to build binutils and gcc together. Is there some doc explaining how to do that?

GCC's HAVE_LTO_PLUGIN=0 in ./host-i686-pc-linux-gnu/gcc/auto-host.h. Does that mean it won't ever work or I just need a better linker at runtime?

Chris

[Jonathan Wakely]

Post by Hite, Christopher
I can't get the linker plugin to work.
g++: error: -fuse-linker-plugin is not supported in this configuration
I build a userland binutils and gcc with dependencies.  I've tried gold and bfd.  Does anyone see anything obvoiusly wrong with this?

You mean apart from the fact you're running ./configure to build GCC,
despite all the documentation saying not to do that?

Also, are you really sure you want to build gmp, mpfr and mpc
separately and install them to non-standard locations? You'll need to
use ldconfig or set LD_LIBRARY_PATH in order to use the gcc
executables. See http://gcc.gnu.org/wiki/InstallingGCC for a simpler
approach.

Post by Hite, Christopher
cd gcc-4.7.0
./configure --with-gmp=$INSTALLATION/gmp-4.3.2 --with-mpfr=$INSTALLATION/mpfr-2.4.2  --with-mpc=$INSTALLATION/mpc-0.8.2  --with-ppl=$INSTALLATION/ppl-0.11 \
       --enable-cloog-backend=isl --with-cloog=$INSTALLATION/cloog-0.16.2 --prefix=$INSTALLATION/gcc-4.7.0 \
       --enable-languages=c,c++ \
       --enable-lto --with-libelf=$INSTALLATION/libelf-0.8.12 --enable-gold
make install
cd binutils-2.22
./configure  --enable-gold --enable-plugins --enable-lto --with-gmp=$INSTALLATION/gmp-4.3.2 --with-mpfr=$INSTALLATION/mpfr-2.4.2  --with-mpc=$INSTALLATION/mpc-0.8.2 \
        --with-ppl=$INSTALLATION/ppl-0.11  --enable-cloog-backend=isl --with-cloog=$INSTALLATION/cloog-0.16.2 --prefix=$INSTALLATION/binutils-2.22 \
       --disable-werror
make all-gold
Do I have the order right?

No. Install binutils first, then install GCC to the *same* prefix.
GCC will automatically use the ld it finds in that location, and as
it's a recent version of binutils it will detect that linker plugin
support works. If you don't want to install GCC and ld to the same
prefix then you can configure GCC with
--with-ld=$INSTALLATION/binutils-2.22/bin/ld (and optionally
--with-as=$INSTALLATION/binutils-2.22/bin/as) but you still need to
install binutils first to do that (think about it: GCC depends on
binutils, not the other way around, so install binutils first.)

Post by Hite, Christopher
Someone mentioned an in-tree build to build binutils and gcc together.  Is there some doc explaining how to do that?

I believe it's not recommended unless you are using the latest sources
from svn for both GCC and binutils.

Since you're trying to install gcc 4.7.0 and binutils 2.22 the shared
top-level config and makefiles might not match.

[Hite, Christopher]

From: Jonathan Wakely

Post by Hite, Christopher
I can't get the linker plugin to work.
g++: error: -fuse-linker-plugin is not supported in this configuration
I build a userland binutils and gcc with dependencies. I've tried gold and bfd. Does anyone see anything obvoiusly wrong with this?

You mean apart from the fact you're running ./configure to build GCC, despite all the documentation saying not to do that?

Sorry didn't notice this.

Also, are you really sure you want to build gmp, mpfr and mpc separately and install them to non-standard locations? You'll need to use ldconfig or set LD_LIBRARY_PATH in order to use the gcc executables. See http://gcc.gnu.org/wiki/InstallingGCC for a simpler approach.

Yeah, I have to do this. I'm not root. I use separate prefixes so I can keep them separate.

No. Install binutils first, then install GCC to the *same* prefix.

The system gcc is so crappy it couldn't build binutils. So I have to build gcc twice.

GCC will automatically use the ld it finds in that location, and as it's a recent version of binutils it will detect that linker plugin support works. If you don't want to install GCC and ld to the same prefix then you can configure GCC with --with-ld=$INSTALLATION/binutils-2.22/bin/ld (and optionally

--with-as=$INSTALLATION/binutils-2.22/bin/as) but you still need to install binutils first to do that (think about it: GCC depends on binutils, not the other way around, so install binutils first.)

This is what caused serious problems for me. Why would your build system look at prefix for dependencies?

It seems like the build ignores the ld I have in my path and uses the system one and decides there's no plugin support.
$which ld
/fs/tools/L4/binutils-2.22/bin/ld
but it ignores that one.

I was looking for a --with-ld. It finally shows up in --help=recursive, but doesn't mention "linker" or anything I guess I was searching for.

I killed a day or two building gcc repeatedly in the background.

Two more dumb questions:
1) Should I / how do I tell do it to build the standard libs with -flto?

2) Does it make sense to combine this with -ffunction-sections, -fdata-sections plus --gc-sections? Or does LTO make that redundant?

Anyway thanks a bunch!!! I was about to give up.

I have a bunch of template recursion that gets reduced this way. My binaries are up to 90% smaller!


Chris

[Jonathan Wakely]

Post by Hite, Christopher
From: Jonathan Wakely

Post by Hite, Christopher
I can't get the linker plugin to work.
g++: error: -fuse-linker-plugin is not supported in this configuration
I build a userland binutils and gcc with dependencies.  I've tried gold and bfd.  Does anyone see anything obvoiusly wrong with this?

You mean apart from the fact you're running ./configure to build GCC, despite all the documentation saying not to do that?

Sorry didn't notice this.

Also, are you really sure you want to build gmp, mpfr and mpc separately and install them to non-standard locations?  You'll need to use ldconfig or set LD_LIBRARY_PATH in order to use the gcc executables. See http://gcc.gnu.org/wiki/InstallingGCC for a simpler approach.

Yeah, I have to do this.  I'm not root.

Did you click on the link and read it? The second "easy way" doesn't
need you to be root.

Post by Hite, Christopher
 I use separate prefixes so I can keep them separate.

Do you actually need those libraries installed for their own sake, or
just because GCC needs them? If you're only installing them for GCC
then it's much easier to follow the method in the link above.

Post by Hite, Christopher

No.  Install binutils first, then install GCC to the *same* prefix.

The system gcc is so crappy it couldn't build binutils.  So I have to build gcc twice.

GCC will automatically use the ld it finds in that location, and as it's a recent version of binutils it will detect that linker plugin support works.  If you don't want to install GCC and ld to the same prefix then you can configure GCC with --with-ld=$INSTALLATION/binutils-2.22/bin/ld (and optionally

--with-as=$INSTALLATION/binutils-2.22/bin/as) but you still need to install binutils first to do that (think about it: GCC depends on binutils, not the other way around, so install binutils first.)
This is what caused serious problems for me.  Why would your build system look at prefix for dependencies?

http://gcc.gnu.org/install/configure.html#with-as

Post by Hite, Christopher
It seems like the build ignores the ld I have in my path and uses the system one and decides there's no plugin support.
$which ld
/fs/tools/L4/binutils-2.22/bin/ld
but it ignores that one.
I was looking for a --with-ld.  It finally shows up in --help=recursive, but doesn't mention "linker" or anything I guess I was searching for.

It's in the installation instructions:
http://gcc.gnu.org/install/configure.html#with-as

Post by Hite, Christopher
I killed a day or two building gcc repeatedly in the background.
1) Should I / how do I tell do it to build the standard libs with -flto?
2) Does it make sense to combine this with -ffunction-sections, -fdata-sections plus --gc-sections?  Or does LTO make that redundant?
Anyway thanks a bunch!!!  I was about to give up.
I have a bunch of template recursion that gets reduced this way.  My binaries are up to 90% smaller!
Chris

[Hite, Christopher]

Post by Hite, Christopher
1) Should I / how do I tell do it to build the standard libs with -flto?
2) Does it make sense to combine this with -ffunction-sections, -fdata-sections plus --gc-sections? Or does LTO make that redundant?

From: Jonathan Wakely

Post by Hite, Christopher
Did you click on the link and read it? The second "easy way" doesn't need you to be root.

The second "easy way" doesn't work for me either. My dev box doesn't have access to the internet. Sometimes I have to ask other people to download stuff for me or encrypt things as mail attachements.
"Commerzbank we hate technology; we wish it would just go away!"

Post by Hite, Christopher
Do you actually need those libraries installed for their own sake, or just because GCC needs them? If you're only installing them for GCC then it's much easier to follow the method in the link above.

So you're suggesting using the same prefix for all of them. That would work, but if I screw-up a step in my install it's harder to untangle what I have to delete.

Post by Hite, Christopher

Post by Hite, Christopher
This is what caused serious problems for me.  Why would your build system look at prefix for dependencies?

http://gcc.gnu.org/install/configure.html#with-as

Crazy, well ok now I know.

Post by Hite, Christopher

Post by Hite, Christopher
I was looking for a --with-ld.  It finally shows up in --help=recursive, but doesn't mention "linker" or anything I guess I was searching for.

Just a suggestion: maybe mention "linker" on that line.
./ configure --help=recursive |grep linker |grep -v LDFLAGS| grep -v LIBS

Chris

[Jonathan Wakely]

Post by Hite, Christopher

Post by Hite, Christopher
1) Should I / how do I tell do it to build the standard libs with -flto?
2) Does it make sense to combine this with -ffunction-sections, -fdata-sections plus --gc-sections?  Or does LTO make that redundant?

I wouldn't bother building the standard libs with LTO personally. Do
you have a reason to think you need to. It's not done by default so
obviously not essential.

Why don't you just keep it simple and try to get a GCC that works with
LTO first?

Post by Hite, Christopher
From: Jonathan Wakely

Post by Hite, Christopher
Did you click on the link and read it?  The second "easy way" doesn't need you to be root.

The second "easy way" doesn't work for me either.  My dev box doesn't have access to the internet.  Sometimes I have to ask other people to download stuff for me or encrypt things as mail attachements.
"Commerzbank we hate technology; we wish it would just go away!"

OK, but if you bothered to look at the download_prerequisities script
you'll see it's downloading the support library sources and putting
them in the GCC source directory. Since you have already downloaded
the files yourself, you could just put them in the GCC dir yourself.

Post by Hite, Christopher

Post by Hite, Christopher
 Do you actually need those libraries installed for their own sake, or just because GCC needs them?  If you're only installing them for GCC then it's much easier to follow the method in the link above.

So you're suggesting using the same prefix for all of them.  That would work, but if I screw-up a step in my install it's harder to untangle what I have to delete.

No, where did I suggest that?

I'm suggesting unpacking the GMP, MPFR and MPC sources in the GCC
source directory (renaming gmp-x.y.z to gmp, and mpfr-x.y.z to mpfr
and mpc-x.y.z to mpc) and then building GCCC without any of --with-gmp
etc.

Here's an earlier version of the page I keep suggesting you read,
which doesn't use download_prerequisites:
http://advogato.org/person/redi/diary/240.html

Please read it. Carefully. I don't write those docs just to amuse
myself. They realy will make it extremely easy to do what you're
trying and failing to do.

As it says at http://gcc.gnu.org/wiki/InstallingGCC
"A major benefit of running srcdir/configure from outside the source
directory (instead of running ./configure) is that the source
directory will not be modified in any way, so if your build fails or
you want to re-configure and build again, you simply delete everything
in the objdir and start again."

If you do what I'm suggesting then:

1) There are fewer steps to screw up
2) GCC automatically builds GMP, MPFR and MPC correctly, so you don't
get a chance to screw that up
3) If you do screw up you just remove the entire build dir and start
again, no uninstalling or figuring out what to remove.

If you prefer to do it the hard way that's fine, but don't expect any
more replies from me. I'm done trying to convince people to follow
easy, foolproof steps, apparently everyone prefers to do things the
hard way then ask why they couldn't get it to work.

Post by Hite, Christopher

Post by Hite, Christopher

Post by Hite, Christopher
This is what caused serious problems for me.  Why would your build system look at prefix for dependencies?

http://gcc.gnu.org/install/configure.html#with-as

Crazy, well ok now I know.

It's not at all crazy. The 'gcc' and 'g++' drivers just run other
executables, including the cc1, cc1plus etc. executables to do
preprocessing and compilation, the as executable to do assembling and
the ld executable to do linking. Looking for all of them in one place
makes perfect sense, and since 'as' and 'ld' aren't part of GCC it
makes sense to see if they're already installed in that same place as
will be used for the other executables it depends on.

Post by Hite, Christopher

Post by Hite, Christopher

Post by Hite, Christopher
I was looking for a --with-ld.  It finally shows up in --help=recursive, but doesn't mention "linker" or anything I guess I was searching for.

Just a suggestion: maybe mention "linker" on that line.
./ configure --help=recursive |grep linker |grep -v LDFLAGS| grep -v LIBS

Feel free to open a bugzilla enhancement request. I'm not going to
change it and nothing will get done by suggesting it on this list.

[Hite, Christopher]

From: Jonathan Wakely

Post by Hite, Christopher
1) Should I / how do I tell do it to build the standard libs with -flto?
2) Does it make sense to combine this with -ffunction-sections, -fdata-sections plus --gc-sections?  Or does LTO make that redundant?

I wouldn't bother building the standard libs with LTO personally. Do you have a reason to think you need to. It's not done by default so obviously not essential.

I'm building one statically linked binary for deployment and I'm pretty sure a bunch of the standard libs is never used. Things like "basic_ifstream<wchar_t..>"

I rebuilt boost with -flto and it make a bunch of weird warnings go away. Maybe I should do the same with the standard libs. On the other hand it doesn't do this automatically maybe there's a reason.

Why don't you just keep it simple and try to get a GCC that works with LTO first?

It does now. Seriously thanks!!!

I'm suggesting unpacking the GMP, MPFR and MPC sources in the GCC source directory (renaming gmp-x.y.z to gmp, and mpfr-x.y.z to mpfr and mpc-x.y.z to mpc) and then building GCCC without any of --with-gmp etc.

I do use them to build binutils.

http://advogato.org/person/redi/diary/240.html

Thanks I wish I would have found this last week!

It's not at all crazy. The 'gcc' and 'g++' drivers just run other executables, including the cc1, cc1plus etc. executables to do preprocessing and compilation, the as executable to do assembling and the ld executable to do linking.
Looking for all of them in one place makes perfect sense, and since 'as' and 'ld' aren't part of GCC it makes sense to see if they're already installed in that same place as will be used for the other executables it depends on.

Yeah, I'd just expect you to look at the shell's path first. That seems to be what other packages do when looking for a compiler, but I'm no expert. Maybe there's some reason to check the path last.

Chris

[Jonathan Wakely]

Post by Hite, Christopher

I'm suggesting unpacking the GMP, MPFR and MPC sources in the GCC source directory (renaming gmp-x.y.z to gmp, and mpfr-x.y.z to mpfr and mpc-x.y.z to mpc) and then building GCCC without any of --with-gmp etc.

I do use them to build binutils.

AFAIK binutils doens't use any of GMP, MPFR or MPC.

The configure help mentions them only because the configure file is
common to GCC and binutils.

[Hite, Christopher]

Post by Jonathan Wakely
AFAIK binutils doens't use any of GMP, MPFR or MPC.
The configure help mentions them only because the configure file is common to GCC and binutils.

AFAIK you're right. I just believed help and thought I should be consistent.



Maybe I'll try -flto on the std libs by setting CFLAGS. You'd think someone would have tried that already.

Chris