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 ---
- To: PostGIS Development Discussion <postgis-devel%postgis.refractions.net@localhost>
- Subject: Re: [postgis-devel] 1.5.0rc2 - FAST TURNAROUND
- From: Greg Troxel <gdt%ir.bbn.com@localhost>
- Date: Wed, 03 Feb 2010 08:19:54 -0500
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: pgpzExSyiuYhI.pgp
Description: PGP signature_______________________________________________ postgis-devel mailing list postgis-devel%postgis.refractions.net@localhost http://postgis.refractions.net/mailman/listinfo/postgis-devel
--- End Message ---
--
Greg Troxel <gdt%ir.bbn.com@localhost>
Attachment:
pgpT23AraRFAA.pgp
Description: PGP signature