Studied this some more, notes from that below.
My question to you is still the same as in the previous email, and that
is:
Is there really not is any mechanism to enforce loading of only ONE
stdc++ version and that one being the NEWEST, in OpenBSD today; so
loading of two etc. happens regularly?
The guys at #gcc (redi) call that "madness", if it's the case. Anyhow
looking forward to your clarification just to understand.
Here are the notes:
-> Studied the C++11 incompatibilities additionally, and emphasis is
still the same.
I studied the C++11 incompatibilities further to clarify this
conversation additionally.
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.
I should put together a code test to test the same thing e.g. make a
dummy binary and library, compile with 4.2.1. and 4.8/9.X, and check
which runtime versions are loaded.
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.
-> C++11 compatibility issues: Not a very big deal. Is a tool available
to analyze a binary for them. However they do exist, even within the
respective G++ version.
Now to C++11, please note the intercompatibility issues not just are
between G++ versions, but *ALSO* between compilation modes, that is
-std=c++03 vs. -std=c++11 even with the same compiler version.
So that is, G++ 4.8.4-compiled C++03-mode-compiled code has certain
compatibility issues with G++ 4.8.4-compiled C++11-mode-compiled code.
This is not because of actual language differences between C++03 and
C++11 (the wiki page says "The C++98 language is ABI-compatible with the
C++11 language"), but because of things like "was fixable and then
fixed", because the GCC team added things like vector::data() (which was
not in the C++03 spec) and then needed to change it to adhere to the
C++11 spec retroactively.
The good news here is that if you go through
https://gcc.gnu.org/wiki/Cxx11AbiCompatibility you see that the
intercompatibility issues, which regard
* some difference in definitions of symbols in certain use cases, and
* some difference in return value type,
which indeed would lead to undefined behavior if it would trig - you see
that
* they are corner cases, and
* that there is a way to analyse if binaries are subject to them
(that's what the upper third of the page is about, the section "How to
get a list of symbols your library exports").
I will have some followup question on how OpenBSD does things later.
-> A possible extreme approach for ensuring correctness of the binary
code
Maybe it could be relevant to make custom compiles of library ports into
a given output directory, with forcing of "eg++ -std=c++11" for *all*
C++ code, to be 100% sure that the code output is correct, in some given
project, though that would be very picky indeed.
Having *all* library dependencies compiled with eg++ would ensure
linking to the right runtime version (there is some other g++/eg++
argument to specify that too so g++ could be used with some other
argument too to that end), and "-std=c++11" would ensure that all binary
code would be free of the potential C++11 intercompatibility issues
mentioned on the wiki page too - so that would total "safety".
(Confirmed that point with redi.)
(That could incur an issue that C++11 not is absolutely backward
compatible with C++03, however, it is mostly backward compatible. E.g.
"auto int i = 0;" would break.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3288.htm
Incompatibilities should essentially always lead to compilation failure
however.)
Anyhow, so, looking forward to your response to question (above and
which is the same 1 & 2 below) and to wrap up with some conclusion.
Thanks again!
Tinker
On 2016-07-07 17:02, Tinker wrote:
..
1)
Are you saying that OpenBSD has *no mechanisms whatsoever* in place
..
2)
I think if you have one and the same OS process where some code is
..
(Looking forward to your clarification on these two still.)
While indeed the ABI compatibility for C++ level
https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html is not
complete, at least it's good.
The ABI compatibility list only lists certain G++ versions - in the
4.8.X and 4.9.X-series, it lists neither 4.8.4 nor 4.9.3 which are
what OpenBSD bundle, but only 4.8.0, 4.8.3 and 4.9.0 - maybe 4.8.4
should be read as 4.8.3, and 4.9.3 should be read as 4.9.0 here,
anyhow again supposedly the compatibility is good.
..And then let's have a look at the C++11X level:
3)
So you mention https://gcc.gnu.org/wiki/Cxx11AbiCompatibility . That
page says that "it govers up to GCC 4.7", which is older than what
(Now updated to saying 6.1, which was correct apparently.)
OpenBSD is working with now.
Can you please help me understand the problem at hand here? -
Also, are you sure there is a problem now considering that C++11X code
only is compiled with >= 4.8.X versions now.. is your worry that
4.2.1-compiled C++ code is incompatible with >=4.8.X-compiled C++11X
code - are you sure there are incompatibilities or is it an unverified
worry of yours?
The biggest problem is X libraries that use C++ (Mesa) when most
large or actively-maintained-upstream C++ ports require a C++11
compiler.
If it only was a question of C++ code, then I guess the libstdc++
version compatibility thing would ensure that it would work, as long
as OpenBSD only would load one single libstdc++ version and that one
would be the newest.
