the recent PR54820 change that adds -static-libstdc++ -static-libgcc to the bootstrap flags ends up putting the LDFLAGS into all subdirs even unrelated to the stage1 bootstrapping for example, if you get the latest sourceware.org tree and try to build gdb, you'll find those flags now showing up in LDFLAGS $ make all-gdb ... gcc -g -O2 -static-libstdc++ \ -o gdb gdb.o ...
Eric, can you please have a look at this?
IMO forcing -static-libstdc++ is a progress, especially on non-Linux platforms, so I don't really see what needs fixing here. Of course people might disagree and tailor this to their needs (and write a patch).
Well, if you can link dynamically, you should, if say libstdc++ contains some security bug and gdb isn't built in the combined tree with gcc, then I'd say it is highly undesirable to link it statically. It is not a big deal when some programs built by gcc are linked statically against libstdc++, if there is a security bug in there, one will have to rebuild gcc anyway. So, perhaps don't add -static-libstdc++ -static-libgcc if not building gcc (gcc/ subdirectory missing, or whatever other check is appropriate)?
> Well, if you can link dynamically, you should, if say libstdc++ contains > some security bug and gdb isn't built in the combined tree with gcc, then > I'd say it is highly undesirable to link it statically. Your point of view is clearly too Linux-centric here. :-) I can assure you that the last thing people want on Solaris on HP-UX is to have to install shared libraries to run GDB.
(In reply to Eric Botcazou from comment #4) that is an end user's decision. the build scripts really have no business forcing this on all random tools including gdb. the bootstrap logic makes sense for bootstrapping, but it should not be used anywhere else.
GCC 4.8.3 is being released, adjusting target milestone.
ping ... this is causing releases of binutils' gold to be statically linked, and causing headaches for the gold testsuites.
GCC 4.8.4 has been released.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
GCC 4.9 branch is being closed
GCC 5 branch is being closed
(In reply to Eric Botcazou from comment #4) > > Well, if you can link dynamically, you should, if say libstdc++ contains > > some security bug and gdb isn't built in the combined tree with gcc, then > > I'd say it is highly undesirable to link it statically. > > Your point of view is clearly too Linux-centric here. :-) I can assure you > that the last thing people want on Solaris on HP-UX is to have to install > shared libraries to run GDB. Hi folks. It's been 4 years with no progress here. Is this becoming a WONTFIX or should we add a toplevel configure flag to give the user an option to opt out of -static-libstdc++ -static-libgcc? The the original patch has a work around, just specify --with-stage1-libs=" " and you won't get the offending behavior :): # In stage 1, default to linking libstdc++ and libgcc statically with GCC # if supported. But if the user explicitly specified the libraries to use, # trust that they are doing what they want. if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then stage1_ldflags="-static-libstdc++ -static-libgcc" fi]) Should we make an explicit configury flag for this behavior instead of the above work around? Should we instead close this as a WONTFIX with a pointer to the following in our docs: --with-stage1-ldflags=flags This option may be used to set linker flags to be used when linking stage 1 of GCC. These are also used when linking GCC if configured with --disable-bootstrap. If --with-stage1-libs is not set to a value, then the default is ‘-static-libstdc++ -static-libgcc’, if supported. Any input would be great.
Closing as WONTFIX. There is a work around, as I have specified in comment #13. See further discussion here: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00471.html