On 2016-07-07 16:27, Stuart Henderson wrote:
On 2016-07-07, Tinker <ti...@openmailbox.org> wrote:
What is OpenBSD's mechanism for ensuring that only ONE lib[e]stdc++
version is loaded by an OS process concurrently
There isn't one. So far we have mostly got lucky, but not always,
for example I know of at least one port that does an LD_PRELOAD to
work around this.
[below]
and that that version loaded is the NEWEST relevant version?
Even just pulling in the newest one isn't always good enough, the
ABI is not quite compatible.
https://gcc.gnu.org/wiki/Cxx11AbiCompatibility
Dear Stuart,
Thank you very much for your response -
And thanks for confirming my very worst fears :)
Three followup Q:s below.
Emm. Now let's see, what's the way forward here (for proofing a
particular program). To start somewhere,
Let's start with looking at the C++-level only:
1)
Are you saying that OpenBSD has *no mechanisms whatsoever* in place for
a process to *NOT* load both libstdc++ (that is
/usr/lib/libstdc++.so.57.0 , I guess that filename is quite persistent,)
*and* libestdc++ (/usr/local/lib/libestdc++.so.16.0 etc.)??
(So if binary A is compiled with 4.2.1. and shared library B is compiled
with 4.8.X and A links to B by "-lB", then there is no mechanism working
against that both libstdc++ and libestdc++ would be concurrently loaded,
but instead, that is what always happens -)
2)
I think if you have one and the same OS process where some code is
compiled with the first and some other code is compiled with the other,
then, if the fact that both are linked-in and loaded doesn't break
things as is already (that is you would have made it work by somehow
making them be able to run segregated in the same OS process, somehow in
separated /name/spaces - I guess that would be needed as I guess they
have state and then supposedly that state would have different format
between the versions), then,
you get potential of total disaster when those two pieces of code
interact, don't you (because if the state was made not to overlap then I
guess the runtimes' structures will be different and that code
interaction would lead to mixing of structures from the different
runtime library versions, which supposedly should lead to crashes)?
So, then, as long as we would be looking at the C++ level only, I guess
just synonymizing libstdc++ with libEstdc++ would work, i.e., make any
attempt to load the older one actually load the newer one.
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
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.
Thanks,
Tinker
