Le 13/06/2012 06:36, Tim Penhey a écrit :
On 13/06/12 04:47, Didier Roche wrote:
Le 12/06/2012 18:22, Matthias Klose a écrit :
On 08.06.2012 17:10, Chris Coulson wrote:
I've just finished debugging a Unity crash which occurs when we try a
test rebuild of Unity and Nux with GCC4.7 in quantal. Although the
original issue was caused by mixing 2 C++ ABI's (because libsigc
hasn't
been rebuilt yet in quantal), it was no better even after rebuilding
libsigc with the quantal toolchain.
correct, afaics there is no ABI incompatibility between 4.6 and 4.7,
but between
c++98 and c++0x/c++11.
c++98 and c++0x/c++11 code should not be mixed in one binary, and best
avoided in a distribution.
This here is the kicker.
What is happening is, in GCC4.7, std::_List_base::_List_impl has a
data
member which only exists for compilation units that are built with
-std=c++0x (_M_size). This means that the STL ABI is dependent on the
language standard. This obviously causes issues when a process loads
libraries that are built with different language standards and which
pass std::list's across public API's
indeed, this is the one issue, which is new in 4.7, so you didn't see
it in
precise with 4.6.
In the Unity case, both Unity and Nux are built with -std=c++0x, but
they use libsigc which is not built with it and which exposes STL
objects in its public API. Rebuilding libsigc locally with
-std=c++0x is
sufficient to make Unity work properly. However, uploading this will
probably break anything else in the archive using libsigc which isn't
built with -std=c++0x, so I'm not sure of the best way to proceed.
both -std=c++0x and -std=c++11 are still marked as experimental. So
don't use
them :-/ I don't think that building c++ libraries for both modes is
the right
approach, so let's avoid that for now, until the c++11 support in 4.7
is more
complete, and maybe not experimental.
Hmm... not entirely sure about this. I'm hoping we can find a
different solution.
Yes, indeed, the situation is suboptimal. as this feature is marked as
experimental. However, I'm afraid that we have an issue about this.
Indeed, Unity is written using a lot of c++11 facilities, and taking it
out won't be trivial now AFAIK. I'm CCing Tim who can give more
information about it.
We started using the --std=c++0x flag about 10 months ago. A large
amount of the code that has been added over that time is using the
more stable parts of the C++11 standard:
* auto variable type
* range based for loops
* strong enums
* lambda functions
Taking those out would be a massive task.
I think Tim is right, and even if we commit to do that, I guess we will
have other developers using the c++11 standards that are not shipped
into the distribution. Ignoring them is not something we should do IMHO.
So "fixing/rollbacking" just Unity doesn't solve the whole problem.
Didier
Tim
--
ubuntu-devel mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
