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
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
