@keithp has a saying:
> There are two types of code: tested code and broken code
Early in my career I thought "nah, there's some code that just works and doesn't need maintenance".
But once again his adage proves true.
Today's example:
A few years ago the Xserver failed to build on SPARC. @thesamesam fixed it in https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/813. The fix added a necessary bit of code to the build that had been missed in the autotools → meson transition.
Recently we discovered it had stopped compiling at some point when GCC became more strict! (Fix: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1751)
@mattst88 @thesamesam oops! in netbsd land we cross build X11 with our own make based system and never noticed this.. we've been happily running X on 32 bit and 64 bit SPARC all millennia :-) we also have a bunch of drivers that need to be merged up stream.
i agree with @keithp now, in my dotage ;)
@mattst88 @thesamesam I should test upstream builds on SPARC more often - I build constantly on Solaris/x86 but fell out of the habit of doing the same on SPARC at some point as upstream development slowed down and things broke rarely. It looks like we didn't hit this in our official package builds since we still build Xorg for Solaris with the Solaris Studio compilers instead of gcc.
@alanc @mattst88 @thesamesam In your experience were Solaris Studio compilers better at using Niagara than gcc?
@ball I can’t say that I ever did a real comparison, especially as pretty much everything I built was compiled to support all non-EOL CPUs, not specific to certain models, and I can’t think of anything I worked on regularly that could benefit from dozens of threads running simultaneously like Niagara could do.