On Fri, May 24, 2013 at 11:00:26AM +0200, Rainer Orth wrote:
> Jakub Jelinek <ja...@redhat.com> writes:
>
> > On Thu, May 23, 2013 at 11:54:05PM +0200, Rainer Orth wrote:
> >> > Agreed, that seems the best course of action if that's an option.
> >>
> >> I just remembered that we aren't there yet even on mainline:
> >>
> >> * This snippet
> >>
> >> http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01255.html
> >>
> >> is necessary to avoid bootstrap failure on Solaris 9.
> >>
> >> * We'll need to link every C++ program with -lrt on Solaris, as
> >> mentioned in the same message. I suppose the best way to do this is
> >> along the lines of libgfortran.spec, rather than duplicate the
> >> necessary configury between g++ and libstdc++. This might prove
> >> pretty invasive for the testsuite, though, and delay the 4.8.1 release
> >> quite a bit.
> >
> > Ugh, that makes =auto pretty much unbackportable, but it seems Solaris is
> > the only problematic OS here. The goal of
> > _ZNSt6chrono12steady_clock3nowEv@@GLIBCXX_3.4.19
> > already in 4.8.1 was to allow Linux users (and with partial backport of
> > =auto not including Solaris perhaps also FreeBSD/NetBSD/OpenBSD) to let
> > users that get C++ core language feature completeness also use this
> > (Jonathan/Benjamin, is that right?).
>
> It occured to me that there might be a far less intrusive option to still
> allow a Solaris backport: instead of going the libstdc++.spec route
> (which I still think is the correct way forward), statically handle -lrt
> addition in g++spec.c, controlled by a macro defined only in config/sol2.h.
>
> Such a patch could be added to mainline and 4.8 branch now, and mainline
> later changed to use libstdc++.spec instead.
I think a switch from not linking libstdc++ against -lrt to linking against
that is quite heavy change for the branch. Do you see why the latest patch
I've posted today wouldn't work well on Solaris?
Jakub
