Thread: 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

Dear Tom,

> 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.

If I just want one extension, I would like to load only that extension. So
I'm really against an artificial "ugly" merge. But it seems ok to me if it
is not artificial.

> 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.

If the makefile needs a lot of work to build several shared libs, I would
suggest to split contrib/spi and possibly others on a one shared lib per
directory basis: contrib/spi_this, contrib/spi_that, contrib/spi_thing,
and thus to rely on Makefile.shlib all the time as you suggest.

Directories are cheap, and I don't think it is bad to separate different
contributions clearly.

On the other hand, if some distinct libs really belong together, then
merge them.

Just my very humble little opinion;-)

Have a nice day,

-- 
Fabien Coelho - coelho@cri.ensmp.fr