handling contrib directories as modules not shared libraries

Lists: pgsql-hackers
From: brook(at)biology(dot)nmsu(dot)edu (Brook Milligan)
To: pgsql-hackers(at)postgresql(dot)org
Cc: brook(at)nmsu(dot)edu
Subject: handling contrib directories as modules not shared libraries
Date: 2010-01-24 01:00:51
Message-ID: 20100124010051.5A9331177E2D@viola.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

It seems that src/Makefile.shlib has special cases for several
directories that build loadable modules rather than shared libraries.
The contrib/adminpack is one of the special cases, but none of the
other contrib directories are. As a result, they get built as shared
libraries (i.e., as libXXX.so rather than XXX.so) and the
corresponding *.sql.in files that load them refer to the wrong file
and therefore fail. The following patch (against the 8.3 release)
fixes this by expanding the set of special cases to include all the
contrib directories, not just contrib/adminpack. I only have tested
this with the uuid module, but it appears that all of them have the
same organization.

--- src/Makefile.shlib.orig
+++ src/Makefile.shlib
@@ -21,7 +21,7 @@
ifneq (,$(findstring src/pl/,$(subdir)))
shmodule = yes
else
-ifneq (,$(findstring contrib/adminpack,$(subdir)))
+ifneq (,$(findstring contrib/,$(subdir)))
shmodule = yes
else
shmodule = no

Cheers,
Brook


From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: Brook Milligan <brook(at)biology(dot)nmsu(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org, brook(at)nmsu(dot)edu
Subject: Re: handling contrib directories as modules not shared libraries
Date: 2010-01-24 16:00:06
Message-ID: 1264348806.18154.5.camel@vanquo.pezone.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On lör, 2010-01-23 at 18:00 -0700, Brook Milligan wrote:
> It seems that src/Makefile.shlib has special cases for several
> directories that build loadable modules rather than shared libraries.
> The contrib/adminpack is one of the special cases, but none of the
> other contrib directories are. As a result, they get built as shared
> libraries (i.e., as libXXX.so rather than XXX.so) and the
> corresponding *.sql.in files that load them refer to the wrong file
> and therefore fail. The following patch (against the 8.3 release)
> fixes this by expanding the set of special cases to include all the
> contrib directories, not just contrib/adminpack. I only have tested
> this with the uuid module, but it appears that all of them have the
> same organization.

This code has been reworked quite extensively since 8.3. Please check
CVS head to see if it works for you.


From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Brook Milligan <brook(at)biology(dot)nmsu(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org, brook(at)nmsu(dot)edu
Subject: Re: handling contrib directories as modules not shared libraries
Date: 2010-01-25 18:52:56
Message-ID: 4B5DE888.8010304@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 1/23/10 5:00 PM, Brook Milligan wrote:
> It seems that src/Makefile.shlib has special cases for several
> directories that build loadable modules rather than shared libraries.
> The contrib/adminpack is one of the special cases, but none of the
> other contrib directories are. As a result, they get built as shared
> libraries (i.e., as libXXX.so rather than XXX.so) and the
> corresponding *.sql.in files that load them refer to the wrong file
> and therefore fail. The following patch (against the 8.3 release)
> fixes this by expanding the set of special cases to include all the
> contrib directories, not just contrib/adminpack. I only have tested
> this with the uuid module, but it appears that all of them have the
> same organization.

Should we be fixing them this way, or fixing the modules so that they
build as shared libraries?

--Josh Berkus