Then the GNU folks could use it or ignore it but they wouldn't be ignorant of problems.
In fact for many issues timely notice is almost all it takes to get things fixed.
A lot of BSD energy goes into making base system work with as little GPL as possible. Is there no non-GPL toolsuite for the embedded systems you're targetting?
I could believe the answer is either, both of (a) no and (b) but I need to keep compatibility with GPL produced .so and related objects.
Which is their right, of course. But it's a little salty to then turn around and demand that the GNU people then be responsible for supporting them anyway.
How maintained can it be if it's not tracking upstream and providing patches, even just to build it? The very premise of your question disproves this assertion.
Look, there was a time when gcc and binutils were the native toolchain on FreeBSD and you could rely on them working as well as they do anywhere. But they aren't anymore, and all the people with the skills to be maintaining a toolchain are working on other software. Binutils is left to rot, honestly.
This isn't because the FSF used to have a CI system, it's because FreeBSD used to have binutils users, and to first approximation it doesn't any more. You're one of the last.
Overall I like BSD licenced code, and I like the approach to minimise dependency on GPL licenced code, but When you get down into things like binary blobs for WiFi units soldered onto mainboards, and Video drivers, things pretty quickly favour the volume of users behind GPL. I just remind myself that 2D non-accellerated graphics are probably what I need even if better 3D is what I want (the binary blobs thing really annoys me)
But in later message you also state:
> Our toolchain is actually GPL-free
It's obviously the conflict of the goals, where you, the way I understand it, can't complain that the GPL-based tools "don't always (in every release) perfectly (i.e. without any adjustments) work" on the platforms whose goal is to avoid the GPL.
You should be lucky that they indeed fix the issues when somebody submits the patches. But the other communities can't expect from the GPL contributors to do the very work for which the said non-GPL communities exist.
Or, in the words of my favourite Microsoft (i.e. non-GPL) developer:
https://blogs.msdn.microsoft.com/oldnewthing/20110118-00
"Don’t just stand around saying somebody should do something: Be someone"
https://man.sr.ht/builds.sr.ht/compatibility.md
You don't need to be an Official Important Binutils Person to set up some CI and use it to make bug reports. You should try it out!
QEMU has this issue -- in theory we support Linux, OSX, Windows, OpenBSD, FreeBSD, NetBSD (and CI on all of those), but Linux support is much better than all the rest because all of the primary developers are using that, and contributions from users of the other platforms are much rarer. It's not a policy decision to treat the others as third-class.
The GNU compiler guys have setup a oldstyle build farm which I've never used, but with savannah et al there's no free CI.
If so, is it really unreasonable for another gnu project to expect you to get gmake first and use that in order to compile the project?
But the whole point of autotools is to write a flavor-agnostic Makefile that gets compiled into a working Makefile. For it not to work defeats the point.
It's just the tool to make the compatible releases possible. The compatibility doesn't fall from the sky, somebody should actively work on it. And you can be that someone.
I have notes I took last product release with a different bug, same scenario.
Unfortunately many GNU projects treat non-Linux platforms as third class citizens (GNU autotools still doesn’t always generate Makefiles compatible with bsdmake).