On 2018-09-14 14:39, Olivier Hainque wrote: > > >> On 13 Sep 2018, at 00:25, Rasmus Villemoes <r...@rasmusvillemoes.dk> wrote: > >>> What happens on your end if you just remove the hack ? > >> Unfortunately, the libstdc++ build breaks: >> >> In file included from >> /usr/powerpc-wrs-vxworks/wind_base/target/h/regs.h:66:0, >> from >> /bld/vestas/auto/work.20180912.214646/gcc-build/gcc/include-fixed/setjmp.h:57, >> from >> /bld/vestas/auto/work.20180912.214646/gcc-build/powerpc-wrs-vxworks/libstdc++-v3/include/csetjmp:42, >> from >> /bld/vestas/auto/work.20180912.214646/gcc-src/libstdc++-v3/include/precompiled/stdc++.h:42: >> /usr/powerpc-wrs-vxworks/wind_base/target/h/arch/ppc/regsPpc.h:33:5: >> error: 'UINT32' does not name a type >> UINT32 cr; /* condition register */ >> ^~~~~~ > > Ah, I see. Thanks for the experiment. > >> I'm happy to add an include of vxCpu in the _ASMLANGUAGE case, along >> with a big comment. But, it's also a small enough patch that we can >> carry it internally, if you prefer that we don't touch this hack upstream. > > I'm fine with a change here. It could only possibly impact inclusions > of regs.h from assembly, and should normally improve that, so the risk > of breaking something is very low.
OK, I'll send an updated patch in a moment, adding the vxCpu include in the _ASMLANGUAGE case and keeping vxTypesOld out of _ASMLANGUAGE. > I wonder how we haven't hit the stop above, as it indicates an > inclusion of regs.h without a prior inclusion of vxTypes from the > VxWorks setjmp.h, included unconditionally from precompiled/stdc++.h > via csetjmp. Maybe different set of headers for different versions > of the OS. Yes, I believe other (newer) versions of VxWorks might have more self-contained headers, so they themselves pull in whatever other headers they rely on. Rasmus
