On Monday 15 June 2015 22:12:46 Marc Mutz wrote:
> > I disagree. I understand what you said, but right now it is possible to
> > switch from libstdc++ to libc++ with no ill effects[*]. So the question
> > is should be asked the other way around: do we knowingly remove this
> > currently-working ability?
>
> On Solaris, back when I still used it, you could switch between the
> RougeWave- based STL, which was essentially frozen in the mid-90s, and
> stlport, which could compile Boost. The two STLs were both binary
> incompatible. The correct solution for this is to provide
> differently-compiled Qt versions, one for each STL.
Correct, but RWstl was not designed to be interoperable with libstdc++. libc++
was. It can be specifically configured to work in a separate (inline) namespace
and it will share the base C++ ABI with libstdc++ (libsupc++).
> But let's take a step back, and review: With Windows out of the picture,
> because it isn't BC with itself, and OS X probably having only one STL,
> which on top is versioned with inline namespaces, that leaves the ability
> to switch between stdlibc++ and libc++, which no other C++ library
> supports, incl., AFAICT, the KDE ones.
Right, that's only between libstdc++ and libc++. The question is which OS that
is relevant for:
a) OS X
b) Linux distributions that properly compile libc++ [*]
c) BSDs that have switched to Clang as the main compiler (e.g, FreeBSD)
> > [*] provided, of course, that the two share their base C++ ABI, which some
> > Linux distros have not yet learned to do.
>
> ...and that not even works on all distributions.
>
> A few years ago, there even wasn't a libc++ to make this argument.
A few years ago, our argument was different: we had the -no-stl option. During
Qt 3 times, that meant binary incompatible builds of Qt. For Qt 4, someone
made it so that the two builds were compatible -- whether that was intentional
or accidental, I don't know (that was before my time). What I did ensure was
that we made that official.
That proved beneficial when Apple decided to create libc++.
> I find this use-case of interchangable std C++ libraries far-fetched ("an
> den Haaren herbeigezogen", for those of you who know German) and not really
> worth pursuing, because it's basically a) the libc++/stdlibc++ developer's
> job to make the two interchangeable, and b) failing that, the distro's and,
> more importantly, the alternative is for us to continue to castrate
> ourselves to a life of poorly re-implemented copies of std:: functionality,
> and reduced interop with the myriad of *other* C++ libraries, both of which
> affects *all* platforms and not just the one that doesn't really need our
> help, because it's doing an excellent job of installed-software management
> already, unlike the others.
It's the same reason why we keep 32-bit OS X builds working: some people using
Qt still need to link against proprietary libraries that are using the "wrong"
options.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
