Hi Rasmus, > On 26 May 2020, at 16:52, Rasmus Villemoes <r...@rasmusvillemoes.dk> wrote: > > Hi Olivier et al > > I'm having quite a bit of trouble getting gcc 10 to build for our > vxworks 5 (5.5.1) target. The first thing I hit is > > #if !defined(_WRS_VXWORKS_MAJOR) > #error "VxWorks version macros needed but not defined" > #endif > > Our version.h doesn't define that macro (however, there's a > _WRS_VXWORKS_5_X defined in vxWorks.h). Amusingly, a few of the system > headers do mention _WRS_VXWORKS_MAJOR, e.g. > > getOptLib.h:#include "vxWorks.h" /* for _WRS_VXWORKS_MAJOR, if defined. */ > > and everywhere in the headers that use that macro, they are careful to > do "#if defined (_WRS_VXWORKS_MAJOR) && (_WRS_VXWORKS_MAJOR >= 6)". > > For now, I've just monkey-patched _vxworks-versions.h to get the build > past that - I suppose what I should do is to patch our version.h > system header instead to provide those two macros. > > But most of the gthread stuff simply doesn't build against our > headers. These five patches, and a bogus definition of WIND_USR > environment variable (-mrtp doesn't make sense for us, but > vx_crtbegin-rtp.o still gets built and that fails if WIND_USR doesn't > exist) get the build a little further - I then fail to build > libstdc++, but I'd like some feedback on whether vxworks 5 is even > supposed to be (still) supported before digging further.
Unfortunately, no, not really: while we don't break it intentionally, it was transitioned to End Of Life a couple of years a ago and we don't test on such configurations any more. We are gradually going to a similar path for VxWorks 6, with 6.8 EOL since July 2019 and 6.9 turned Legacy early 2020 after ~9 years out. Your message comes in timely - I was about to send a note mentioning this soon now, as we are starting a transition of all our production toolchains to gcc-10 and we are resuming posting updates upstream as stage1 has just reopened. The system environment on 5 and 6 is essentially frozen. Maintaining new versions of gcc operational on such legacy versions is increasingly difficult with every release as incompatibilities of various degrees of subtlety keep creeping in. Build failures are one thing and can often be addressed, but we have witnessed, for example, issues with newer dwarf constructs incorrectly processed by the system unwind lib or wrong code gen problems on arm for vx6 related to the use of a long deprecated ABI. We can take patches that are reported as helping such cases, as we have done in the past, as long as they are localized and look generally good. But as I mentioned, we are not in a position to really test vx5 configurations any more. The series you sent seem to fit well and I'm getting to them more closely. Thanks Olivier > Rasmus Villemoes (5): > libgcc: vxwors: stub out VX_ENTER_TLS_DTOR for vxworks 5 > gthr-vxworks.h: fix leftover _VXW_PRE_69 > gthr-vxworks.c: add include of taskLib.h > libgcc: vxworks: don't set __GTHREAD_HAS_COND for vxworks 5.x > libgcc: vxworks: don't set __GTHREAD_CXX0X for vxworks 5.x > > libgcc/config/gthr-vxworks-cond.c | 4 ++++ > libgcc/config/gthr-vxworks-thread.c | 4 ++++ > libgcc/config/gthr-vxworks-tls.c | 5 +++++ > libgcc/config/gthr-vxworks.c | 1 + > libgcc/config/gthr-vxworks.h | 10 +++++++--- > 5 files changed, 21 insertions(+), 3 deletions(-) > > -- > 2.23.0 >
