Hi Rasmus, > On 04 Jun 2020, at 15:31, Rasmus Villemoes <r...@rasmusvillemoes.dk> wrote: > >> 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? AdaCore. >> 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. Sounds good, thanks. Out of curiosity, what is your main motivation for keeping upgrading the compiler version on such an environment ? Do you have plans to move to a more recent version of VxWorks at some point ? > 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? A priori, I think we could do that as long as it's indeed similar to the existing vxworksae variant in terms of amount/kind of alternate sources and impact. I don't think we should go as far as entirely insulating the vx5 support. We had an issue of the exact same kind when we worked on the introduction of VxWorks7 support, and keeping things factorized helped a lot on a number of accounts. I understand the situation we're discussing is a bit different but most of the benefits remain valid I think. The changes you have so far look generally good (thanks again for proposing them!) and it seems worth pursuing a bit in this direction. I hope the changes we have in the pipe won't make it harder. The vast majority are testsuite updates and ports to other architectures. Otherwise, at a quick glance, a couple of fixincludes related bits which we might even need to revisit before upstreaming, and a minor libstdc++ configuration adjustment. They were issued with at least up to vx6 still in mind and I don't know of cases where we deliberately introduced something with the conscious knowledge that it would break older configurations. For sure, not in a fundamental impossible to recover fashion. Olivier
