[OE-core] [RFC][PATCH] gcc-runtime.inc: force libstdc++ to always use gcc4 compatible ABI

Khem Raj raj.khem at gmail.com
Wed Jan 27 05:13:21 UTC 2016


> On Jan 26, 2016, at 12:18 PM, Andre McCurdy <armccurdy at gmail.com> wrote:
> 
> On Tue, Jan 26, 2016 at 8:38 AM, Khem Raj <raj.khem at gmail.com> wrote:
>> 
>>> On Jan 26, 2016, at 12:10 AM, Andre McCurdy <armccurdy at gmail.com> wrote:
>>> 
>>> Experimental hack, not expected to be merged.
>>> 
>>> Without this, the http://www.cplusplus.com/reference/string/string/append/
>>> example fails to build with -std=c++11 and it's not clear why (it's as if we
>>> build a version of libstdc++ which supports only the old ABI but with headers
>>> which try to use the new ABI when compiled with -std=c++11 ?). As a workaround,
>>> force libstdc++ to provide, and default to using, the old ABI in all cases.
>>> 
>>> See also:
>>> 
>>> https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html
>>> https://mail.gnome.org/archives/gtkmm-list/2015-June/msg00026.html
>>> https://wiki.debian.org/GCC5
>>> 
>>> Signed-off-by: Andre McCurdy <armccurdy at gmail.com>
>>> ---
>>> meta/recipes-devtools/gcc/gcc-runtime.inc | 13 +++++++++++++
>>> 1 file changed, 13 insertions(+)
>>> 
>>> diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc b/meta/recipes-devtools/gcc/gcc-runtime.inc
>>> index f20d298..3a476cd 100644
>>> --- a/meta/recipes-devtools/gcc/gcc-runtime.inc
>>> +++ b/meta/recipes-devtools/gcc/gcc-runtime.inc
>>> @@ -10,6 +10,19 @@ EXTRA_OECONF_PATHS = "\
>>> 
>>> EXTRA_OECONF_append_linuxstdbase = " --enable-clocale=gnu"
>>> 
>>> +# gcc-runtime.inc: force libstdc++ to always use gcc4 compatible ABI
>>> +# Experimental hack. Without this, the http://www.cplusplus.com/reference/string/string/append/
>>> +# example fails to build with -std=c++11 and it's not clear why (it's as if we
>>> +# build a version of libstdc++ which supports only the old ABI but with headers
>>> +# which try to use the new ABI when compiled with -std=c++11 ?). As a workaround,
>>> +# force libstdc++ to provide, and default to using, the old ABI in all cases.
>>> +# See also:
>>> +# https://gcc.gnu.org/onlinedocs/libstdc++/manual/configure.html
>>> +# https://mail.gnome.org/archives/gtkmm-list/2015-June/msg00026.html
>>> +# https://wiki.debian.org/GCC5
>>> +#
>>> +EXTRA_OECONF_append = " --disable-libstdcxx-dual-abi --with-default-libstdcxx-abi=gcc4-compatible”
>> 
>> This change while makes it work compatible to older libstdc++ ABI, we should make the defaults to be
>> forward looking.
> 
> Yes, I agree. The problem is that currently our libstdc++ doesn't seem
> to support the new ABI.
> 
>> I would rather keep --with-default-libstdcxx-abi=c++11 since gcc6 will switch to newer
>> c++ std as default. If we revert like you suggest, we will be up for more work in gcc6 time.
>> 
>> please define _GLIBCXX_USE_CXX11_ABI=0 for your app, where you see the problem.
> 
> My test case is the example app from:
> 
>  http://www.cplusplus.com/reference/string/string/append/
> 
> It fails when I try to compile to use the new ABI (ie by using
> -stdc++11 or _GLIBCXX_USE_CXX11_ABI=1).

Lets not mix API ( std=c++11 ) and libstdc++ c++11 ABI, both are different.

have you tried the converse where you suspect the test is not c++11 ABI compliant for STL
in particular

str.append<int>(5,0x2E);

> 
> There is no legacy code involved.
> 
>> 
>>> RUNTIMETARGET = "libssp libstdc++-v3 libgomp libatomic \
>>>    ${@bb.utils.contains_any('FORTRAN', [',fortran',',f77'], 'libquadmath', '', d)} \
>>> "
>>> --
>>> 1.9.1
>>> 
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core at lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20160127/7e33c3c5/attachment-0002.sig>


More information about the Openembedded-core mailing list