tech-pkg archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

postgresql Makefile.shlib replacement - should we be doing this?

In postgresql84, we replace a Makefile.shlib that upstream thinks works
fine with a version that uses libtool.  This runs into trouble with
postgis, which assumes that postgresql makefiles don't use libtool
(which they don't).

Plus, our replacement appears not to correctly deal with the two
separate cases of:

  shared library in $libdir/libfoo.so.maj.min

  pgsql module in $pkglibdir/foo.so  (different dir, no lib, no maj/min!!)

and this is making things difficult for the postgis package, as well as
diverging from upstream.

So, would anyone object to no longer replacing Makefile.shlib?  If so,
could you edit the postgresql84-client Makefile and add comments
explaining why this replacement is necessary and why on balance it's a
good idea?  I'm not saying it's not - just that I don't understand and
it's not documented.
--- Begin Message --- 
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.

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.

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.  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%siriusit.co.uk@localhost>

  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.

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

Attachment: pgpQa4LypkpZW.pgp
Description: PGP signature

_______________________________________________
postgis-devel mailing list
postgis-devel%postgis.refractions.net@localhost
http://postgis.refractions.net/mailman/listinfo/postgis-devel

--- End Message ---

Attachment: pgpuhl_SZUibu.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index