[postgis-devel] 1.5.0rc2 - FAST TURNAROUND

Thu Feb 4 06:19:44 PST 2010

Mark Cave-Ayland <mark.cave-ayland at siriusit.co.uk> writes:

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

Yes, I think it would be mostly fine, except for the lack of rpath in
commands in loader due to not including LDFLAGS.  (I will try to send a
patch for that.)

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

Understood.  The problem is that postgresql includes what is essentially
the functionality of libtool, but done again by hand for lots of
systems, and this results in different files being installed on
different operating systems.  Using libtool means that there aren't
shlib linking issues and specifying the libtool .la file in the list of
packaged files works everywhere (because there's already generic support
for libtool).  None of this is postgis's problem of course.

The real problem is that the module is misnamed and that's just a bug in
our litbool reimplementation and thus mine to fix.

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

I'll ask the person who maintains the package; the bits are sitting in
public CVS and available.  Probably libtool could be used on everything
but windows.

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

It is.  Using libtool seems like a legit way to build modules on a
platform, and passing .a files to module/lib link lines expecting that
to work seems to rely on the details of how postgresql builds now.

I understand of course that this can't reasonably be done for 1.5.

It would make sense to me to just make liblwgeom a shared library using
the postgresql standard makefile, and then install it and have it used
both by the module and pgsql2shp.  That's what pkgsrc does to get around
the "libtool rejects .a libs being linked into shlibs" problem.

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

OK - it would be nice to explain that somewhere, perhaps a simple:

# The normal case is to overrride parts of pgxs.mk in order to support
# installing the module in a versioned subdirectory.

just before the conditional in the makefile.  Maybe it's written down
but it was something I had trouble figuring it out.

I've appended the replacement file if you want to look at it.  Obviously
there is some brokenness but the basic notion is to use libtool for
building shared objects and libraries.

----------------------------------------

#-------------------------------------------------------------------------
#
# Makefile.libtool
#    Common rules for buildling libtool archives
#
# IDENTIFICATION
#    $NetBSD: Makefile.libtool,v 1.1.1.1 2009/07/29 06:26:18 adam Exp $
#
#-------------------------------------------------------------------------

##
## Hacks/workarounds for makefiles in certain directories
##

# The following directories are building loadable shared modules, not
# shared libraries.
#
ifneq (,$(findstring src/backend/utils/mb/conversion_procs/,$(subdir)))
shmodule	= yes
else
ifneq (,$(findstring src/backend/snowball,$(subdir)))
shmodule	= yes
else
ifneq (,$(findstring src/pl/,$(subdir)))
shmodule	= yes
else
ifneq (,$(findstring contrib/adminpack,$(subdir)))
shmodule	= yes
else
shmodule	= no
endif
endif
endif
endif

# Fix dependencies in some makefiles that assume the target matches
# %.o so that when built for libtool, the target matches the corresponding
# %.lo.
#
ifeq ($(subdir), src/interfaces/ecpg/ecpglib)
path.lo: path.c $(top_builddir)/src/port/pg_config_paths.h
endif

ifeq ($(subdir), src/interfaces/libpq)
fe-connect.lo: fe-connect.c $(top_builddir)/src/port/pg_config_paths.h
endif

ifeq ($(subdir), src/pl/plpgsql/src)
pl_gram.lo pl_handler.lo pl_comp.lo pl_exec.lo pl_funcs.lo: plpgsql.h
pl_gram.lo: $(srcdir)/pl_scan.c
endif

##
## VARIABLE DEFINITIONS
##

# Loadable shared modules are named differently from shared libraries
# and are installed into $(pkglibdir).
#
ifeq ($(shmodule),yes)
ltlib		= $(NAME)$(DLSUFFIX)
ltmodule	= -module
rpathdir	= $(pkglibdir)
else
ltlib		= lib$(NAME)$(DLSUFFIX)
ltmodule	=
endif

DLSUFFIX	= .la
SO_MAJOR_VERSION?=0
SO_MINOR_VERSION?=0

LTCOMPILE	= $(LIBTOOL) --mode=compile $(CC) $(CFLAGS) $(CPPFLAGS)
LTLINK		= $(LIBTOOL) --mode=link $(CC) $(LDFLAGS) $(ltmodule) -rpath $(rpathdir) -version-info $(SO_MAJOR_VERSION):$(SO_MINOR_VERSION)
LTOBJS		= $(OBJS:%.o=%.lo)

# Define INSTALL_SHLIB and shlib for the benefit of Makefiles for
# loadable modules that have their own target for installing the
# module.
#
INSTALL_LTLIB	= $(LIBTOOL) --mode=install $(INSTALL)
INSTALL_STLIB	= $(INSTALL_LTLIB)
INSTALL_SHLIB	= $(INSTALL_LTLIB)
shlib		= $(ltlib)

%.lo : %.c
	$(LTCOMPILE) -c $< -o $@

##
## BUILD
##

.PHONY: all-lib all-static-lib all-shared-lib all-la-lib
all-lib all-static-lib all-shared-lib: all-la-lib

all-la-lib: $(ltlib)

$(ltlib): $(LTOBJS)
	$(LTLINK) -o $@ $(LTOBJS) $(SHLIB_LINK)

##
## INSTALL
##

.PHONY: install-lib install-lib-static install-lib-shared installdirs-lib install-lib-la
install-lib install-static-lib install-shared-lib: install-lib-la

install-lib-la: $(ltlib)
ifeq ($(shmodule),yes)
	$(INSTALL_LTLIB) $< $(DESTDIR)$(pkglibdir)/$(shlib)
else
	$(INSTALL_LTLIB) $< $(DESTDIR)$(libdir)/$(ltlib)
endif

installdirs-lib:
ifeq ($(shmodule),yes)
	$(mkinstalldirs) '$(DESTDIR)$(pkglibdir)'
else
	$(mkinstalldirs) '$(DESTDIR)$(libdir)'
endif

##
## UNINSTALL
##

.PHONY: uninstall-lib
uninstall-lib:
	$(LIBTOOL) --mode=uninstall rm -f $(DESTDIR)$(libdir)/$(ltlib)

##
## CLEAN
##

.PHONY: clean-lib
clean-lib:
	$(LIBTOOL) --mode=clean rm -f $(ltlib) $(LTOBJS)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20100204/022401c4/attachment.sig>