fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

11K
active users

@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.

mattst88 :gentoo:

Today's example:

A few years ago the Xserver failed to build on SPARC. @thesamesam fixed it in gitlab.freedesktop.org/xorg/xs. 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: gitlab.freedesktop.org/xorg/xs)

GitLabhw/xfree86: fix sbus build for SPARC (!813) · Merge requests · xorg / xserver · GitLabInitially reported downstream in Gentoo. Manifests with errors like: gnu/bin/ld: hw/xfree86/common/libxorg_common.a(xf86fbBus.c.o): in function `xf86ClaimFbSlot':...
#sparc#xorg#xserver

@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.