[postgis-devel] 1.5.0rc2 - FAST TURNAROUND

[Mark Cave-Ayland]

Greg Troxel wrote:

> Paul and Mark: Thanks for the replies - I have been unclear on what
> might be a local/pkgsrc issue vs. a postgis issue, and not really clear
> on how things are supposed to work, but thanks to your replies and
> further off-list clarification from Mark I'm mostly over that now.

No worries.

> pkgsrc is a packaging system, much like fink or darwinports, but it runs
> on a large number of platforms rather than just one (half a dozen
> operating systems, many more cpus).  Programs are built for /usr/pkg,
> and /usr/pkg/lib is not in the default system run-time linker search
> path, so rpath is used.  Thus, pkgsrc often finds missing rpath usage in
> packages that don't show up on Linux, where everything is in /usr.

Hmmm. So if pkgsrc is a customised build system, am I right in assuming 
that a standard build of the PostgreSQL and PostGIS sources outside of 
pkgsrc works just fine?

> I have dug in further and think that part/most of the issue is that
> pkgsrc replaces Makefile.shlib with a version that uses libtool.

Gulp. If pkgsrc has taken it upon themselves to rewrite an upstream 
Makefile.shlib then I don't feel that we can offer much in the way of 
support for this.

I also seem to remember way back in the mists of time that the 
PostgreSQL build system was based upon a hacked-up version of libtool 
which was in its infancy at the time, possibly because it was broken on 
some platforms. Perhaps if all these issues are fixed, you could 
consider offering the changes upstream?

> pkgsrc
> has separately made sure that libtool really works correctly on all
> supported platforms, so there's a bias to use it for making shared
> libraries, and that seems overzealous in this case.  I think there are
> two resulting issues:
> 
> 1) aspects of the replacement are incorrect (naming, library placement).
> This is of course ours to fix, or to decide to stop doing the
> replacement.
> 
> 2) postgis assumes that postgresql mk files don't use libtool (the way
> liblwgeom.a is constructed and then used in postgis/Makefile.in).  And
> probably related, postgis assumes it can overwrite targets in pgsql mk
> files.
> 
> and then there are some very minor issues about missing LDFLAGS/rpath.
> 
>   From: Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk>
> 
>   AFAICT the library naming problem is not ours, whereas possibly the
>   attempted linking of a static library into a dynamic executable is
>   ours. I think in legacy times the compile flags were different for
>   static and dynamic object files which is why libtool is complaining -
>   but strangely NetBSD seems to be the only platform complaining about
>   this...
> 
> postgresql (8.4) doesn't use libtool, so it makes sense that the
> pkgsrc-modified Makefile.shlib is the only reason you are getting
> complaints about libtool objecting to linking with .a.
> 
> What pkgsrc did for 1.4.1 was:
> 
>   change the module name and path in postgis.sql to work around pkgsrc's
>   pgsql mk replacement putting it in the wrong place (wrong fix, our
>   action to resolve)
> 
>   use libtool to build and link liblwgeom, making it a real shared
>   library (this is the hard case)
> 
>   use libtool to build/link pgsql2shp, causing it to get the right
>   LDFLAGS, particularly rpath.  I'll see if I can send a patch to
>   address the missing rpath issue within the context of postgis's
>   current build system, as that's a far simpler and less invasive fix.
> 
> It seems very unusual to build objects intended to be in a shlib and
> then stick them in .a.  It seems legitimate, although unconventional in
> the postgresql world, to use libtool to build objects for a postgresql
> module and to merge them into a module.  I am guessing the liblwgeom.a
> mechanism is because of history (there's a comment about previous
> installed shlibs), and wonder whether it would be better to either make
> it a real library (with libtool in postgis, and install it) or to just
> include the source files in the postgis module and not have it be
> anything like a library.  But, I see pgsql2shp uses liblwgeom, so it has
> to be at least a bit like a library.

If the .a archive is causing issues then maybe we could look at 
combining separate .o files into a module in the same way that 
PostgreSQL does. But that's not going to happen in the 1.5 time frame 
I'm afraid.

> pgsql's Makefile.shlib seems to support building a normal shared library
> (such as would be installed in $libdir and then used by a module in
> $pkglibdir), and also modules.  So it seems liblwgeom should be built
> and installed as a shared library, but I suspect I'm missing something.
> 
> I am still having trouble following the pgxs override logic.  Is doing
> the override and using the versioned directory intended to be the normal
> case?  (It looks like it was in my build, but I don't trust that.)

Yeah; the functionality required to implement this was only committed in 
PostgreSQL 9.0 (was 8.5 at the time) and so anything older than this 
will need to use the override targets. It's a horrible hack, but at 
least we can remove it a few years down the line ;)


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs