Bug 56750 - [6/7/8 Regression] static -lstdc++ logic bleeds into all subdirs
Summary: [6/7/8 Regression] static -lstdc++ logic bleeds into all subdirs
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.8.0
: P2 normal
Target Milestone: 6.5
Assignee: Not yet assigned to anyone
URL:
Keywords: build
Depends on: 54820
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-27 05:33 UTC by Mike Frysinger
Modified: 2019-08-11 14:31 UTC (History)
12 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-03-24 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Frysinger 2013-03-27 05:33:11 UTC
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 ...
Comment 1 Jakub Jelinek 2014-02-18 15:17:03 UTC
Eric, can you please have a look at this?
Comment 2 Eric Botcazou 2014-02-18 15:53:10 UTC
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).
Comment 3 Jakub Jelinek 2014-02-18 16:01:08 UTC
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)?
Comment 4 Eric Botcazou 2014-02-18 16:41:42 UTC
> 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.
Comment 5 Mike Frysinger 2014-02-18 17:24:57 UTC
(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.
Comment 6 Richard Biener 2014-05-22 09:01:51 UTC
GCC 4.8.3 is being released, adjusting target milestone.
Comment 7 Mike Frysinger 2014-09-09 22:22:52 UTC
ping ... this is causing releases of binutils' gold to be statically linked, and causing headaches for the gold testsuites.
Comment 8 Jakub Jelinek 2014-12-19 13:28:06 UTC
GCC 4.8.4 has been released.
Comment 9 Richard Biener 2015-06-23 08:17:41 UTC
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
Comment 10 Jakub Jelinek 2015-06-26 19:53:54 UTC
GCC 4.9.3 has been released.
Comment 11 Richard Biener 2016-08-03 10:59:56 UTC
GCC 4.9 branch is being closed
Comment 12 Jakub Jelinek 2017-10-10 13:27:17 UTC
GCC 5 branch is being closed
Comment 13 Aldy Hernandez 2018-02-02 19:16:37 UTC
(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.
Comment 14 Aldy Hernandez 2018-02-09 07:53:06 UTC
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