* vxworks libstdc++ locale
@ 2021-12-21 15:42 Rasmus Villemoes
2021-12-22 9:21 ` Rasmus Villemoes
0 siblings, 1 reply; 2+ messages in thread
From: Rasmus Villemoes @ 2021-12-21 15:42 UTC (permalink / raw)
To: Corentin Gay; +Cc: Olivier Hainque, gcc-patches
Hi
While trying to upgrade our vxworks 5.5 compiler to gcc12, I've hit a
problem when loading the libstdc++ module on target. It manifests as
[00] tShell memPartFree: invalid block 8bf72c in partition 9605dc.
[00] tShell memPartFree: invalid block 8bf38c in partition 9605dc.
[00] tShell memPartFree: invalid block 8bf304 in partition 9605dc.
[00] tShell memPartFree: invalid block 8bf348 in partition 9605dc.
[00] tShell memPartFree: invalid block 8bf23c in partition 9605dc.
[00] tShell memPartFree: invalid block 8bf6c4 in partition 9605dc.
[00] tShell memPartFree: invalid block 8bf794 in partition 9605dc.
[00] tShell memPartFree: invalid block 8bf7a0 in partition 9605dc.
[00] tShell memPartFree: invalid block 8bf7bc in partition 9605dc.
being printed on the console. We didn't use to pass an explicit
--enable-clocale option to configure, but if I add
--enable-clocale=generic , thus reverting to the locale implementation
used for gcc11, the problem goes away.
The vxworks locale seems to be mostly identical to generic, just
differing in CCTYPE_CC. And comparing the .a files, it seems that that
TU ends up defining a constructor
_GLOBAL__sub_I__ZNSt12ctype_bynameIcEC2EPKcj , which calls
_ZNSt8ios_base4InitC1Ev . But then I'm lost.
Any ideas?
Rasmus
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: vxworks libstdc++ locale
2021-12-21 15:42 vxworks libstdc++ locale Rasmus Villemoes
@ 2021-12-22 9:21 ` Rasmus Villemoes
0 siblings, 0 replies; 2+ messages in thread
From: Rasmus Villemoes @ 2021-12-22 9:21 UTC (permalink / raw)
To: Corentin Gay; +Cc: Olivier Hainque, gcc-patches
On 21/12/2021 16.42, Rasmus Villemoes wrote:
> Hi
>
> While trying to upgrade our vxworks 5.5 compiler to gcc12, I've hit a
> problem when loading the libstdc++ module on target. It manifests as
>
> [00] tShell memPartFree: invalid block 8bf72c in partition 9605dc.
> [00] tShell memPartFree: invalid block 8bf38c in partition 9605dc.
> [00] tShell memPartFree: invalid block 8bf304 in partition 9605dc.
> [00] tShell memPartFree: invalid block 8bf348 in partition 9605dc.
> [00] tShell memPartFree: invalid block 8bf23c in partition 9605dc.
> [00] tShell memPartFree: invalid block 8bf6c4 in partition 9605dc.
> [00] tShell memPartFree: invalid block 8bf794 in partition 9605dc.
> [00] tShell memPartFree: invalid block 8bf7a0 in partition 9605dc.
> [00] tShell memPartFree: invalid block 8bf7bc in partition 9605dc.
>
> being printed on the console. We didn't use to pass an explicit
> --enable-clocale option to configure, but if I add
> --enable-clocale=generic , thus reverting to the locale implementation
> used for gcc11, the problem goes away.
>
> The vxworks locale seems to be mostly identical to generic, just
> differing in CCTYPE_CC. And comparing the .a files, it seems that that
> TU ends up defining a constructor
> _GLOBAL__sub_I__ZNSt12ctype_bynameIcEC2EPKcj , which calls
> _ZNSt8ios_base4InitC1Ev . But then I'm lost.
>
> Any ideas?
So if I remove the
#include <iostream>
from libstdc++-v3/config/locale/vxworks/ctype_members.cc the problem
goes away, and I don't see the purpose of that #include anyway (a debug
leftover perhaps?).
Rasmus
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-12-22 9:21 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-12-21 15:42 vxworks libstdc++ locale Rasmus Villemoes
2021-12-22 9:21 ` Rasmus Villemoes
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).