Dumb shlib build rules cause regression test failures on ia64

I am seeing regression test failures on HPUX 11.23 (on ia64) using gcc
3.4.1. The failures occur because refint.so fails to load:

/usr/lib/hpux32/dld.so: Unsatisfied code symbol '__divdi3' in load module '/house/tgl/pgsql/src/test/regress/../../../contrib/spi/refint.so'.
ERROR: could not load library "/house/tgl/pgsql/src/test/regress/../../../contrib/spi/refint.so": Unresolved external

Several of the contrib regression tests fail similarly. The problem is
that the .so files get linked without mentioning libgcc.a, and
apparently this platform won't resolve the references to link to the
same routines in the backend.

There is no problem with modules that are linked using Makefile.shlib,
because it knows to add the appropriate libgcc reference to the link.
But the "MODULES" branch in pgxs.mk is not as smart. It's effectively
relying on the DLSUFFIX rule supplied by the platform-specific makefile.
Those rules have always been a few bricks shy of a load, IMHO.

The obvious solution to this is to use Makefile.shlib all the time,
but there's a problem: Makefile.shlib is only designed to build a single
shlib per build subdirectory, and contrib/spi wants to build several.
I don't see any easy way to rejigger Makefile.shlib to support multiple
shared libraries at once --- anyone see a way?

A klugy workaround is to build all the modules in contrib/spi into a
single shared library. This is ugly but I can't level any worse charge
than "ugly" against it.

The other contrib modules build no more than one shared library apiece,
and could trivially be converted to the MODULE_big build path. Or more
likely, redefine the MODULES case in pgxs.mk to support only one module
in a directory, and use Makefile.shlib all the time.

Comments?

regards, tom lane