On Fri, 14 Mar 2014, Rainer Orth wrote: > Rainer Orth <r...@cebitec.uni-bielefeld.de> writes: > > >>> > For this particular case at least. > >>> > > >>> > Note that I'm not against linking against static libgcc_s for > >>> > lto-plugin. The -static-libstdc++ we use is just because during > >>> > bootstrap picking up the correct libstdc++ was deemed too hard > >>> > to implement and thus the easy way out was -static-libstdc++. > >>> > >>> So how should we go forward with this issue? This bootstrap failure is > >>> a regression from all previous releases. As I said, I'd rather not > >>> duplicate the -static-libgcc test from the toplevel, but would do so if > >>> all else fails. Perhaps Paolo could weigh in as the build maintainer? > >> > >> Yeah, I'd like a build maintainer to look over your first proposed patch > >> (workaround libtools nicyness). > > > > Just one additional data point: I've checked mainline libtool, and it > > still doesn't handle (meaning: still drops) > > -static-libgcc/-static-libstdc++. At least they have some hints in > > their documentation on what testing etc. it takes to get additional > > options passed through to the compiler/linker. > > I'm now testing this alternative. So far, I've just manually configured > lto-plugin with CC=cc (Solaris Studio cc, no -static-libgcc) and CC=gcc > and found that -static-libgcc is only used with gcc, as expected. I've > checked that -static-libgcc is supported as far back as 3.4.6 (probably > even far older), so the $GCC check should be enough.
Yeah, only -static-libstdc++ is relatively new. And we require at least GCC 3.4.x for bootstrapping anyway. > I'm including it in this weekend's bootstraps on Solaris and Linux. Looks good to me, thus ok if the bootstraps work. Thanks, Richard.
