On 2019/11/12 11:45, Chris Ross wrote: > > > > On Nov 12, 2019, at 00:25, Stuart Henderson <s...@spacehopper.org> wrote: > > > > sparc64 isn't on upstream's list of supported architectures > > (https://golang.org/doc/install/source). > > > > There's a third party fork adding this for an old version of go > > (https://github.com/4ad/go) but even with this it's going to be a lot of > > work to get something usable, and even then there will be problems building > > many programs that bundle a "vendored" copy of standard go libraries that > > will need updating before they can be used. > > > > It's likely to be much easier to rewrite the tools you want in C than it is > > to get go working.
> Well, I don’t know how easy that would be either. These were both, I Seriously it's a relatively simple program. Not belittling it, but it takes messages via opensmtpd's filter interface, passes them to rspamd over http, and feeds the result back to opensmtpd. Porting that to a different language is a complete different magnitude of complexity than porting a (not-upstream-supported version of) the go compiler and standard library to OpenBSD/sparc64. (...of course it doesn't have to be C, some other language with json+http support would also work). Also note that we don't have luajit for sparc64 either, so rspamd will use more resources / be slower on sparc64 than one of the arches that do support this. > believe, written by Gilles. I would appreciate your input Gilles. I see > both of these particularly tools, opensmtpd filters, are Golang only and > require nothing beyond the standard library. It would be ugly, but I > might be able to hack them into my system with the go fork you mention > above. Whether or not I _want_ to is more complicated. :-/ > > Side note: if something isn't present in release packages on some > > particular arch (but is present for other arch), it's not going to build > > directly from ports > > Okay. Thanks. I’m new to OpenBSD, and I know some other BSD’s work based on > people building and supplying packages, which sometimes take longer on some > of the less used arch’s. We don't take 3rd party binaries, they are built on OpenBSD's own hardware infrastructure by OpenBSD develoeprs. Fewer packages are available on the less common arches, but this is usually because many of them require additional work to make them build at all, and many developers only have the more common arches.
