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
