Thank you very much for your feedback, I need to do more proper testing
to understand this better (that is answer my personal bigger Q about how
to do some C++ things and C++11 things in a really safe way, and part of
that is to understand lib[e]stdc++ behavior), so time for me to do
homework.
Until then briefly,
On 2016-07-08 13:20, Philip Guenther wrote:
And it boils down to the same thing as pointed out in the previous
emails, which is that *not more than one* lib[e]stdc++ must be loaded
at
the same time, and that that should be the newest one.
Maybe if this is a problem for a development setup, then the setup is
too
complicated? Solving a problem by making greater complexity possible
instead of pushing back on the complexity is not always a good thing.
Yeah. I need to do more homework to understand how it plays out.
For me personally, the problem I'm working with is that I have some code
and dependencies that require "eg++ --std=C++11", so I'm just trying to
understand the whole big picture of how to do this safely in my
particular program.
A better solution would be to kick out the whole C++11 thing altogether
and go with C++-98/03, or better yet, no C++ at all!
However no such luck for me this time!..
So, as clarified previously the just-load-one-and-that's-the-newest
policy about lib[e]stdc++ is all needed for inter-g++-version
intercompatibility for "C++03" code.
Of problems that *I'm* interested in solving, that is *waaaaay* down on
the list. Oops, I ran out of space and it fell off. Maybe when I get
some other stuff done I'll come back around and put it back on the
bottom
of the list. By then, C++O3 may be totally obsolete and we can ignore
it
and move on.
Wait, I think your response on this one reflects that maybe you missed
what I meant, this is a fairly insignificant detail but just for clarity
-
C++98 and C++03 are essentially the same thing, the latter standard
amends the further with some fixes, that's all.
C++98 is the C++ standard that G++ 4.2.1 (the OS-bundled version)
compiles.
(https://gcc.gnu.org/onlinedocs/gcc-4.2.1/gcc/C-Dialect-Options.html#C-Dialect-Options
, https://en.wikipedia.org/wiki/C%2B%2B#Standardization)
What I meant here was just that
* For any given G++-generated binary code to "guaranteedly" work
perfectly, two things need to be true, and that is
1) That lib[e]stdc++'s just-load-one-and-that's-the-newest policy is
satisfied (because otherwise you're xyz:ed, that's
all that I've been told anyhow), and
2) Either it must all be compiled in the same C++ mode (98/03 or 11
respectively), or it must not use any of the symbols
that cause friction between the 98/03- and 11-C++ modes (listed
at https://gcc.gnu.org/wiki/Cxx11AbiCompatibility);
actual problems from [98/03 vs. 11] compatibility issues are very
or extremely rare however
(Also, I was told in vague terms that the libstdc++ itself is
c++-language-mode-agnostic as its code not involves any
of the friction points.)
(https://gcc.gnu.org/wiki/Cxx11AbiCompatibility)
,
AND, accordingly,
* Just in case ALL your code is compiled only in 98/03-mode, then of
course you need to pay attention only to 1) .
That was all.
Now only to make this picture complete, then, if you need C++11 mode
then the safe way would be to compile *all* your C++ code including all
dependency ports only in that mode, so that would be using "eg++
--std=c++11".
(The default language mode for G++ 4.8.4 and 4.9.3 (that's eg++) is the
"gnu++03" mode which is a variant of C++03;
https://gcc.gnu.org/onlinedocs/gcc-4.8.4/gcc/C-Dialect-Options.html#C-Dialect-Options
,
https://gcc.gnu.org/onlinedocs/gcc-4.9.3/gcc/C-Dialect-Options.html#C-Dialect-Options
.)
Anyhow the topic of possible 98/03 vs. 11 incompatibilities (and if ever
relevant, forcing C++11-mode on C++ port dependencies) are *totally*
beyond me now, what I need to do now is homework about lib[e]stdc++
loading behavior.
On 2016-07-08 16:59, Marc Espie wrote:
[..]
The guys at GCC made a conscious decision to switch to GPLv3,
Yeah that sucks.
and also to stop dropping platforms that we still use, sometimes
unintentionally
because the monster has grown too big to fit into a cute small
architecture.
That too, totally, and it also highlights that something has gone wrong
on their side (and Miod Vallat pointed that out a long time ago too
http://marc.info/?l=openbsd-misc&m=137530560232232&w=2 ), anyhow.
[..]
BTW, we don't really fancy gcc or libstdc++ all that much because of
the licence.
Am all with you on this one.
