On 03/06/2020 19.41, Olivier Hainque wrote: > Hi Rasmus, > >> On 26 May 2020, at 16:52, Rasmus Villemoes <r...@rasmusvillemoes.dk> wrote: >> >> 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.
Hi Olivier, Thanks for the answer, though obviously not what I was hoping for. Just for the record, who exactly are "we" above? > 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. I (and my customer) am willing to put in some effort to make (or keep) gcc working for vxworks 5. In case the ifdeffery in the existing vxworks-related files becomes too unwieldy, would it be possible to create a separate vxworks5 target, similar to the existing vxworksae variant? Thanks, Rasmus
