On Tue, Jul 1, 2014 at 12:46 PM, Merlin Moncure <mmonc...@gmail.com> wrote: > A few years back I ported the postresql client libraries and a few > other pieces of software (in particular subversion) to a lot of > obscure platforms (old sparc, hpux, irix, older aix, etc etc). > Getting a modern gcc working on those platforms (with the possible > exception of aix) is in many cases difficult or impossible. So > requiring new gcc is exactly equivalent to desupporting.
I took a look around to see which operating systems support which hardware platforms. It's a little hard to tell who is supporting which operating systems, because the terminology is different on different project web sites, and it's hard to tell which things are actually ARMv5, as opposed to something else. But it seems that NetBSD is has by far the largest list of supported platforms, and it appears that they compile their current releases with either gcc 4.5 or gcc 4.8, depending on the particular port: http://www.netbsd.org/developers/features/ According to http://www.netbsd.org/ports/ the ports that run on some form of ARM are acorn26, acorn32, cats, epoc32, evbarm, hpcarm, iyonix, netwinder, shark, and zaurus. epoc32 is not listed at all on the features link above, but the others are all listed as using gcc 4.8.x. Even if they were using gcc 4.5.x, though, that would be good enough, and most platforms that are now on 4.8.x were on 4.5.x before the 4.8.x import got done: http://mail-index.netbsd.org/tech-userlevel/2014/02/18/msg008484.html Apparently, the last holdout preventing removal of gcc 4.1.x from NetBSD was the vax port, which has happily now been upgraded to 4.8.x. Debian also supports ARMv5; actually, they support ARMv4t and higher: https://wiki.debian.org/ArmEabiPort Debian has shipped a sufficiently-new compiler for our purposes since 6.0 (squeeze), released in 2009: https://packages.debian.org/squeeze/gcc So it's clearly *possible* to get newer gcc versions running on ARMv5. I will grant you that it may not be the easiest thing to do on an existing installation. But I don't think having us continue to ship either known-broken code or completely-untested code is any better. If someone needs to get PostgreSQL 9.5 running on ARMv5 using an older gcc, they can test Andres's already-posted patch and, if it works, we can commit it. What I think doesn't make sense is to ship it untested and claim we have support when that really might or might not be true. Also, none of this would affect the PostgreSQL client libraries that you are talking about. s_lock.h is only used by the backend. The bottom line is that I love supporting obscure platforms as much as anyone here, and several other committers are already telling me that I love it too much. We've got to draw the line somewhere, and I think refusing to ship newly-written code that we have exactly zero means of testing is a pretty good place to draw it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
