SCO OpenServer and SCO UnixWare are more or less dead platforms.
We have never had a buildfarm member testing the "sco" port, and
the last "unixware" member was last heard from in 2012, so it's
fair to doubt that the code even compiles anymore on either one.
Remove both ports.  We can always undo this if someone shows up
with an interest in maintaining and testing these platforms.

Discussion: <17177.1476136994@sss.pgh.pa.us>

We've had support for using unnamed POSIX semaphores instead of System V
semaphores for quite some time, but it was not used by default on any
platform.  Since many systems have rather small limits on the number of
SysV semaphores allowed, it seems desirable to switch to POSIX semaphores
where they're available and don't create performance or kernel resource
problems.  Experimentation by me shows that unnamed POSIX semaphores
are at least as good as SysV semaphores on Linux, and we previously had
a report from Maksym Sobolyev that FreeBSD is significantly worse with
SysV semaphores than POSIX ones.  So adjust those two platforms to use
unnamed POSIX semaphores, if configure can find the necessary library
functions.  If this goes well, we may switch other platforms as well,
but it would be advisable to test them individually first.

It's not currently contemplated that we'd encourage users to select
a semaphore API for themselves, but anyone who wants to experiment
can add PREFERRED_SEMAPHORES=UNNAMED_POSIX (or NAMED_POSIX, or SYSV)
to their configure command line to do so.

I also tweaked configure to report which API it's selected, mainly
so that we can tell that from buildfarm reports.

I did not touch the user documentation's discussion about semaphores;
that will need some adjustment once the dust settles.

Discussion: <8536.1475704230@sss.pgh.pa.us>

We weren't terribly consistent about whether to call Apple's OS "OS X"
or "Mac OS X", and the former is probably confusing to people who aren't
Apple users.  Now that Apple has rebranded it "macOS", follow their lead
to establish a consistent naming pattern.  Also, avoid the use of the
ancient project name "Darwin", except as the port code name which does not
seem desirable to change.  (In short, this patch touches documentation and
comments, but no actual code.)

I didn't touch contrib/start-scripts/osx/, either.  I suspect those are
obsolete and due for a rewrite, anyway.

I dithered about whether to apply this edit to old release notes, but
those were responsible for quite a lot of the inconsistencies, so I ended
up changing them too.  Anyway, Apple's being ahistorical about this,
so why shouldn't we be?

In de6fd1c8 I moved the the work around from 53f73879 into the aix
template. The previous location was removed in the former commit, and I
thought that it would be nice to emit a warning when running configure.

That didn't turn out to work because at the point the template is
included we don't know whether we're compiling a 32/64 bit binary and
it's possible to install compilers for both on a 64 bit kernel/OS.

So go back to a less ambitious approach and define
PG_FORCE_DISABLE_INLINE in port/aix.h, without emitting a warning. We
could try a more fancy approach, but it doesn't seem worth it.

This requires moving the check for PG_FORCE_DISABLE_INLINE in c.h to
after including the system headers included from therein which isn't
perfect, as it seems slightly more robust to include all system headers
in a similar environment. Oh well.

Discussion: 20150807132000.GC13310@awork2.anarazel.de

Per buildfarm members mandrill and hornet.

So far we have worked around the fact that some very old compilers do
not support 'inline' functions by only using inline functions
conditionally (or not at all). Since such compilers are very rare by
now, we have decided to rely on inline functions from 9.6 onwards.

To avoid breaking these old compilers inline is defined away when not
supported. That'll cause "function x defined but not used" type of
warnings, but since nobody develops on such compilers anymore that's
ok.

This change in policy will allow us to more easily employ inline
functions.

I chose to remove code previously conditional on PG_USE_INLINE as it
seemed confusing to have code dependent on a define that's always
defined.

Blacklisting of compilers, like in c53f7387, now has to be done
differently. A platform template can define PG_FORCE_DISABLE_INLINE to
force inline to be defined empty.

Discussion: 20150701161447.GB30708@awork2.anarazel.de

xlc provides "long long" unconditionally at C99-compatible language
levels, and this option provokes a warning.  The warning interferes with
"configure" tests that fail in response to any warning.  Notably, before
commit 85a2a890, it interfered with the
test for -qnoansialias.  Back-patch to 9.0 (all supported versions).

Autoconf has known about automatically selecting -Ae when needed for
quite some time now, so remove the redundant addition in template/hpux.
Noted while setting up buildfarm member pademelon.

Support for running postgres on Alpha hasn't been tested for a long
while. Due to Alpha's uniquely lax cache coherency model it's a hard
to develop for platform (especially blindly!) and thought to be
unlikely to currently work correctly.

As Alpha is the only supported architecture for Tru64 drop support for
it as well. Tru64's support has ended 2012 and it has been in
maintenance-only mode for much longer.

Also remove stray references to __ksr__ and ultrix defines.

This preserves user-specified LDFLAGS; we already kept user-specified
CFLAGS and CPPFLAGS.  Given the shortage of complaints and the fact that
any problem caused is likely to appear at build time, no back-patch.

Dag-Erling Smørgrav and Noah Misch

Disabling auto-import requires that all libraries we use be careful about
declspecs for exported variables; and it seems they aren't.  This means
that Cygwin will not give us useful info about missing PGDLLIMPORT markers;
but it's probably sufficient that MSVC and Mingw builds do.

This is evidently the default on buildfarm member narwhal, but that
is a pretty ancient Mingw version, and there is reason to think that
more recent versions of GNU ld have this feature turned on by default.
Since we are trying to achieve consistency of link behavior across
all Windows toolchains, let's just make sure here.

This is expected to make it start failing when contrib modules
reference non-PGDLLIMPORT'ed global variables, as the other Windows
build methods do.  Aside from the value of consistency, the underlying
implementation of this switch is pretty ugly and not really something
we want to rely on if we have to use PGDLLIMPORT anyway for MSVC.

This removes the remaining pieces of the IRIX port that was removed by
ea91a6be.

Apparently, on some glibc versions this causes warnings when
optimization is not enabled.

Altogether, there appear to be too many incompatibilities surrounding
this.

There are apparently some incompatibilities, per buildfarm.

Many distributors use this, so we might as well see the warnings as
well.

Postgres 9.2, and perhaps no existing users either.

Remove the following ports:

- dgux
- nextstep
- sunos4
- svr4
- ultrix4
- univel

These are obsolete and not worth rescuing.  In most cases, there is
circumstantial evidence that they wouldn't work anymore anyway.

at end of files.

since Apple shipped a compiler that needed this switch, and there's
increasing interest in using other compilers that won't accept the switch
at all.  Better to let anybody who still needs the switch inject it via
CPPFLAGS.  Per gripe from Neil Conway.

linking both executables and shared libraries, and we add on LDFLAGS_EX when
linking executables or LDFLAGS_SL when linking shared libraries.  This
provides a significantly cleaner way of dealing with link-time switches than
the former behavior.  Also, make sure that the various platform-specific
%.so: %.o rules incorporate LDFLAGS and LDFLAGS_SL; most of them missed that
before.  (I did not add these variables for the platforms that invoke $(LD)
directly, however.  It's not clear if we can do that safely, since for the
most part we assume these variables use CC command-line syntax.)

Per gripe from Aaron Swenson and subsequent investigation.

on AIX with a non-gcc compiler.  The previous coding would do this only if
CC was exactly "xlc"; which is a bad idea, as demonstrated by trouble report
from Mihai Criveti.

This basically takes some build system code that was previously labeled
"Solaris" and ties it to the compiler rather than the operating system.

Author: Julius Stroffek <Julius.Stroffek@Sun.COM>

and up), per Chris Marcellino.  This avoids consuming O(N^2) file
descriptors to support N backends.  Tests suggest it's about a wash for
small installations, but large ones would have a problem.

it ought to know that you need -DLINUX_PROFILE on Linux.

--enable-debug is used, to avoid complaints about debugging and
optimization being mutually exclusive. Patch from Stefan Kaltenbrunner.

works, but some platform templates overwrote it without asking.

assembler files, renamed as solaris_x86.s.

Theo Schlossnagle

MemSet on AIX by setting MEMSET_LOOP_LIMIT to zero.

Add optimization to skip MemSet tests in MEMSET_LOOP_LIMIT == 0 case and
just call memset() directly.