Обсуждение: perl interface bug?
I am having problems getting the perl interface to work (but see below
for a fix). If I install postgresql on a bare system (i.e., one with
no previous postgresql installed), the perl interface gets installed,
but the test.pl script fails with an undefined symbol error (libpq
cannot be found). However, if I rebuild the perl interface AFTER
postgresql (actually, I think libpq is all that is necessary here) is
installed, the test.pl script works fine.
It seems that the installation procedure should be the following:
- build postgresql (including the perl interface)
- install postgresql, particularly libpq
- rebuild the perl interface
- reinstall the perl interface
The following patches accomplish the following:
- change interfaces/Makefile to reflect the order above by doing a
make clean in perl5 before installing the perl interface; this
forces a rebuild after libpq has been installed. Note that
perl-makefile-dep is no longer required under this scheme.
- create Makefile.PL.in for perl5 so that the installed path for libpq
(as determined by configure) can be incorporated into the ld path
when the perl interface library is built.
- fix configure.in to create Makefile.PL from Makefile.PL.in
NOTE: rerun autoconf
NOTE: delete interfaces/perl5/Makefile.PL
Cheers,
Brook
===========================================================================
--- interfaces/Makefile.orig Wed Oct 7 01:00:23 1998
+++ interfaces/Makefile Tue Oct 13 16:29:16 1998
@@ -15,13 +15,11 @@
include $(SRCDIR)/Makefile.global
-perl-makefile-dep :=
-ifeq ($(USE_PERL), true)
- perl-makefile-dep := perl5/Makefile
-endif
+PERL_CLEAN := DO_NOTHING
+install: PERL_CLEAN := clean
-.DEFAULT all install clean dep depend distclean: $(perl-makefile-dep)
+.DEFAULT all install clean dep depend distclean:
$(MAKE) -C libpq $@
$(MAKE) -C ecpg $@
ifeq ($(HAVE_Cplusplus), true)
@@ -33,6 +31,8 @@
$(MAKE) -C libpgtcl $@
endif
ifeq ($(USE_PERL), true)
+ -$(MAKE) -C perl5 $(PERL_CLEAN)
+ $(MAKE) perl5/Makefile
$(MAKE) -C perl5 $@
endif
ifeq ($(USE_ODBC), true)
===========================================================================
--- interfaces/perl5/Makefile.PL.in.orig Mon Oct 12 16:25:23 1998
+++ interfaces/perl5/Makefile.PL.in Mon Oct 12 16:25:00 1998
@@ -0,0 +1,68 @@
+#-------------------------------------------------------
+#
+# $Id: Makefile.PL,v 1.9 1998/09/27 19:12:21 mergl Exp $
+#
+# Copyright (c) 1997, 1998 Edmund Mergl
+#
+#-------------------------------------------------------
+
+use ExtUtils::MakeMaker;
+use Config;
+use strict;
+
+# because the perl5 interface is always contained in the source tree,
+# we can be sure about the location of the include files and libs.
+# For development and testing we still test for POSTGRES_HOME.
+#
+#print "\nConfiguring Pg\n";
+#print "Remember to actually read the README file !\n";
+#die "\nYou didn't read the README file !\n" unless ($] >= 5.002);
+#
+#if (! $ENV{POSTGRES_HOME}) {
+# warn "\$POSTGRES_HOME not defined. Searching for PostgreSQL...\n";
+# foreach(qw(../../../ /usr/local/pgsql /usr/pgsql /home/pgsql /opt/pgsql /usr/local/postgres /usr/postgres
/home/postgres/opt/postgres)) {
+# if (-d "$_/lib") {
+# $ENV{POSTGRES_HOME} = $_;
+# last;
+# }
+# }
+#}
+#
+#if (-d "$ENV{POSTGRES_HOME}/lib") {
+# print "Found PostgreSQL in $ENV{POSTGRES_HOME}\n";
+#} else {
+# die "Unable to determine PostgreSQL\n";
+#}
+
+my %opts;
+
+if (! $ENV{POSTGRES_HOME}) {
+
+ my $cwd = `pwd`;
+ chop $cwd;
+
+ %opts = (
+ NAME => 'Pg',
+ VERSION_FROM => 'Pg.pm',
+ INC => "-I$cwd/../libpq -I$cwd/../../include",
+ OBJECT => "Pg\$(OBJ_EXT)",
+ LIBS => ["-L@prefix@/lib -L$cwd/../libpq -lpq"],
+ );
+
+} else {
+
+ %opts = (
+ NAME => 'Pg',
+ VERSION_FROM => 'Pg.pm',
+ INC => "-I$ENV{POSTGRES_HOME}/include",
+ OBJECT => "Pg\$(OBJ_EXT)",
+ LIBS => ["-L$ENV{POSTGRES_HOME}/lib -lpq"],
+ );
+}
+
+
+WriteMakefile(%opts);
+
+exit(0);
+
+# end of Makefile.PL
===========================================================================
--- configure.in.orig Mon Oct 12 01:00:20 1998
+++ configure.in Mon Oct 12 16:26:35 1998
@@ -959,6 +961,7 @@
interfaces/libpgtcl/Makefile
interfaces/odbc/GNUmakefile
interfaces/odbc/Makefile.global
+ interfaces/perl5/Makefile.PL
pl/plpgsql/src/Makefile
pl/plpgsql/src/mklang.sql
pl/tcl/mkMakefile.tcldefs.sh
Brook Milligan <brook@trillium.NMSU.Edu> writes:
> I am having problems getting the perl interface to work (but see below
> for a fix). If I install postgresql on a bare system (i.e., one with
> no previous postgresql installed), the perl interface gets installed,
> but the test.pl script fails with an undefined symbol error (libpq
> cannot be found). However, if I rebuild the perl interface AFTER
> postgresql (actually, I think libpq is all that is necessary here) is
> installed, the test.pl script works fine.
This is a longstanding problem in the Perl module. It's fairly closely
related to the recent flamefest about LD_LIBRARY_PATH, btw --- the
trouble is that if shared lib A refers to shared lib B, then lib A may
need to contain a hardwired path to lib B. At least on some platforms.
I think your intended fix of rebuilding the Perl shared lib after libpq
has been installed might solve the problem nicely for these platforms.
HPUX is one of the places where there's a problem, so I'll try out your
fix as soon as I get a chance.
If this flies, we should rip out the commented-out cruft in
perl5/Makefile.PL.in, and probably also remove its use of POSTGRES_HOME
environment variable...
regards, tom lane
Brook Milligan <brook@trillium.NMSU.Edu> writes: > I am having problems getting the perl interface to work (but see below > for a fix). If I install postgresql on a bare system (i.e., one with > no previous postgresql installed), the perl interface gets installed, > but the test.pl script fails with an undefined symbol error (libpq > cannot be found). However, if I rebuild the perl interface AFTER > postgresql (actually, I think libpq is all that is necessary here) is > installed, the test.pl script works fine. This is a longstanding problem in the Perl module. It's fairly closely related to the recent flamefest about LD_LIBRARY_PATH, btw --- the trouble is that if shared lib A refers to shared lib B, then lib A may need to contain a hardwired path to lib B. At least on some platforms. I think your intended fix of rebuilding the Perl shared lib after libpq has been installed might solve the problem nicely for these platforms. Yes, that seems to be the problem, though I don't quite recognize why libpgtcl works (it has the same libpgtcl refers to libpq feature, but I tried it quite awhile ago with pgaccess and all was fine). Perhaps there is a subtle difference between the ld command for it and the once constructed for perl. I chose this approach (i.e., make clean, rebuild perl stuff after install) because I didn't want to gut the automatic perl Makefile.PL stuff, which I don't understand completely. To me this seemed like a fairly clean solution, but anything better from the perl wizards is welcome. HPUX is one of the places where there's a problem, so I'll try out your fix as soon as I get a chance. Please let me know how it works. I'd like to see this fixed in 6.4 since it will remove a substantial bug in the perl interface. If this flies, we should rip out the commented-out cruft in perl5/Makefile.PL.in, and probably also remove its use of POSTGRES_HOME environment variable... Absolutely. That stuff really isn't necessary, I don't think. I just didn't want to trash the file so dramatically. :) Cheers, Brook
Brook Milligan <brook@trillium.NMSU.Edu> writes:
> Yes, that seems to be the problem, though I don't quite recognize why
> libpgtcl works (it has the same libpgtcl refers to libpq feature, but
> I tried it quite awhile ago with pgaccess and all was fine).
On HPUX, the reason libpgtcl works as a shared lib is that it gets
installed into the same library directory as libpq. HPUX uses a search
path for shared libs (typically embedded into the executable, though you
can arrange to look at an environment variable instead if you're so
inclined). So, if the application was able to find libpgtcl, it'll
find libpq too.
I imagine that generally the same story holds for other systems,
but haven't looked closely.
The reason the Perl module fails is that it gets installed somewhere
else, viz. the perl library tree. The Perl executable knows about
looking in the library tree for shlibs, but it's never heard of
/usr/local/pgsql/lib/ unless you hack it specially.
It might be that installing a copy of libpq.so into the same directory
that the perl module shlib goes into would make it work. I haven't
tried that, but if it works it might be a better answer than this
rebuild-afterwards approach.
regards, tom lane
> Please let me know how it works. I'd like to see this fixed in 6.4 > since it will remove a substantial bug in the perl interface. > > If this flies, we should rip out the commented-out cruft in > perl5/Makefile.PL.in, and probably also remove its use of POSTGRES_HOME > environment variable... > > Absolutely. That stuff really isn't necessary, I don't think. I just > didn't want to trash the file so dramatically. :) Added to Open 6.4 items list. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Tom Lane wrote: > > Brook Milligan <brook@trillium.NMSU.Edu> writes: > > I am having problems getting the perl interface to work (but see below > > for a fix). If I install postgresql on a bare system (i.e., one with > > no previous postgresql installed), the perl interface gets installed, > > but the test.pl script fails with an undefined symbol error (libpq > > cannot be found). However, if I rebuild the perl interface AFTER > > postgresql (actually, I think libpq is all that is necessary here) is > > installed, the test.pl script works fine. > > This is a longstanding problem in the Perl module. It's fairly closely > related to the recent flamefest about LD_LIBRARY_PATH, btw --- the > trouble is that if shared lib A refers to shared lib B, then lib A may > need to contain a hardwired path to lib B. At least on some platforms. > I think your intended fix of rebuilding the Perl shared lib after libpq > has been installed might solve the problem nicely for these platforms. > > HPUX is one of the places where there's a problem, so I'll try out your > fix as soon as I get a chance. > > If this flies, we should rip out the commented-out cruft in > perl5/Makefile.PL.in, and probably also remove its use of POSTGRES_HOME > environment variable... > > regards, tom lane I think the best solution is just not to build the perl interface together with postgresql. It will never work, because 'make test' needs the postmaster to be up and running. Don't change Makefile.PL, POSTGRES_HOME is needed when building the perl module outside the postgresql source-tree. Edmund -- Edmund Mergl mailto:E.Mergl@bawue.de Im Haldenhau 9 http://www.bawue.de/~mergl 70565 Stuttgart fon: +49 711 747503 Germany
It might be that installing a copy of libpq.so into the same directory that the perl module shlib goes into would make it work. I haven't tried that, but if it works it might be a better answer than this rebuild-afterwards approach. NO, NO, NO! We don't want TWO copies of libpq floating around. The correct solution, I think, is to make the libraries know about each other. My patch does that, though there may be other solutions that do the same thing. What we need is to determine if there are cases in which that rebuild after install method does not work. Cheers, Brook
I think the best solution is just not to build the perl interface together with postgresql. It will never work, because 'make test' needs the postmaster to be up and running. I will argue strongly that we DO want to build the perl interface straight out of the box. Ideally we will have a COMPLETE system that can be built and installed in one pass, such that every part of it will work. I have demonstrated that it is possible (at least on NetBSD) to do this and still resolve the inter-library references between the perl interface and libpq. We cannot kill this idea because 'make test' doesn't run without the postmaster. After all, NONE of the regression tests do either! Nevertheless, we still build and install the complete system; then run the tests. The same is applicable to the perl interface. Don't change Makefile.PL, POSTGRES_HOME is needed when building the perl module outside the postgresql source-tree. This may be the case and is a good reason to include the conditional in Makefile.PL. Nothing is really lost by doing so. Cheers, Brook
Brook Milligan <brook@trillium.NMSU.Edu> writes:
> We cannot kill this idea because 'make test' doesn't run without the
> postmaster. After all, NONE of the regression tests do either!
Edmund is thinking of a different situation. The perl5 interface is
also a "Perl module", which means that it is supposed to build and
install under very rigid rules --- this is supposed to work:
perl Makefile.PL
make
make test
make install
If you were installing the perl5 module separately from Postgres proper,
and already had a running Postgres server, that should indeed work.
(With the caveat that you first have to set POSTGRES_HOME environment
variable to /usr/local/pgsql or local equivalent.)
It's not *entirely* clear to me that that's a very plausible scenario,
since we distribute the perl5 module along with Postgres. But it does
work and we probably shouldn't break it.
Come to think of it, Brook's proposed changes do break the perl5
directory as a standalone Perl module, because it no longer includes a
Makefile.PL, only a Makefile.PL.in. Can we avoid that by finding some
other way to get the install target directory name into the perl5
makefile? Maybe, instead of being rewritten by autoconf, Makefile.PL
could actively go look for the directory name, say by looking to see if
../../Makefile.global exists and contains a POSTGRESDIR= line. If not,
fall back to requiring POSTGRES_HOME to be set.
regards, tom lane
Edmund is thinking of a different situation. The perl5 interface is
also a "Perl module", which means that it is supposed to build and
install under very rigid rules --- this is supposed to work:
perl Makefile.PL
make
make test
make install
Ok, I see now. So, we need the following:
- a Makefile.PL that works out of the box for the above sequence,
given that POSTGRES_HOME is set properly.
- a Makefile.PL that works with the Postgres installation and gets the
right shared library, so if we run `make test' later (or use the
interface in any way) it works immediately upon Postgres
installation.
A solution:
- a default Makefile.PL that works
- a Makefile.PL replaced from Makefile.PL.in that still works with the
above, but satisfies the second criterion.
The patches below do this and I think satisfy all considerations
(you'll let me know if they don't, right? :)
- Makefile.PL has an explanation and if POSTGRES_HOME is not set will
print a useful message.
- Makefile.PL.in replaces that message with the right thing for
finding the installed shared library based on configure.
- Makefile: same as before; do the clean before installing to pick up
the right shared library. Note that no clean is done for any other
targets.
- configure.in: output Makefile.PL along with the rest. Note also,
that in the current version $WHOAMI is never set so the perl test
always fails. Perhaps this should be fixed by setting the variable
correctly, but in any case the comments no longer agree with this
stuff anyway.
Cheers,
Brook
===========================================================================
--- Makefile.PL.orig Thu Oct 15 11:13:55 1998
+++ Makefile.PL Thu Oct 15 12:16:33 1998
@@ -1,4 +1,3 @@
-# Generated automatically from Makefile.PL.in by configure.
#-------------------------------------------------------
#
# $Id: Makefile.PL,v 1.9 1998/09/27 19:12:21 mergl Exp $
@@ -11,29 +10,25 @@
use Config;
use strict;
-# because the perl5 interface is always contained in the source tree,
-# we can be sure about the location of the include files and libs.
-# For development and testing we still test for POSTGRES_HOME.
-#
-#print "\nConfiguring Pg\n";
-#print "Remember to actually read the README file !\n";
-#die "\nYou didn't read the README file !\n" unless ($] >= 5.002);
-#
-#if (! $ENV{POSTGRES_HOME}) {
-# warn "\$POSTGRES_HOME not defined. Searching for PostgreSQL...\n";
-# foreach(qw(../../../ /usr/local/pgsql /usr/pgsql /home/pgsql /opt/pgsql /usr/local/postgres /usr/postgres
/home/postgres/opt/postgres)) {
-# if (-d "$_/lib") {
-# $ENV{POSTGRES_HOME} = $_;
-# last;
-# }
-# }
-#}
-#
-#if (-d "$ENV{POSTGRES_HOME}/lib") {
-# print "Found PostgreSQL in $ENV{POSTGRES_HOME}\n";
-#} else {
-# die "Unable to determine PostgreSQL\n";
-#}
+# This Makefile.PL is intended for standalone use when PostgreSQL is
+# already installed. In that case, install the perl module as follows:
+#
+# setenv POSTGRES_HOME /path/to/root/of/installed/postgres
+# perl Makefile.PL
+# make
+# make test
+# make install
+
+# During normal installation of PostgreSQL, this file will be replaced
+# by one derived from Makefile.PL.in so that the installed shared
+# library libpq.so will be found during installation of this module.
+# As a result, the POSTGRES_HOME environment variable need not be set
+# during PostgreSQL installation. Note that ../Makefile takes care of
+# the `perl Makefile.PL' command. Note also that it is still possible
+# to follow the standalone installation procedure, even after
+# configuring and installing PostgreSQL, because the `else'
+# conditional branch below is identical in both Makefile.PL and
+# Makefile.PL.in.
my %opts;
@@ -42,13 +37,16 @@
my $cwd = `pwd`;
chop $cwd;
- %opts = (
- NAME => 'Pg',
- VERSION_FROM => 'Pg.pm',
- INC => "-I$cwd/../libpq -I$cwd/../../include",
- OBJECT => "Pg\$(OBJ_EXT)",
- LIBS => ["-L/usr/pkg/pgsql/lib -L$cwd/../libpq -lpq"],
- );
+ print "To install the perl interface for PostgreSQL do the following:\n";
+ print " - install PostgreSQL\n";
+ print " - set the POSTGRES_HOME environment variable appropriately\n";
+ print " - in this directory ($cwd):\n";
+ print " perl Makefile.PL\n";
+ print " make\n";
+ print " make test [ with a postmaster running ]\n";
+ print " make install\n";
+
+ exit(1);
} else {
===========================================================================
--- interfaces/perl5/Makefile.PL.in.orig Thu Oct 15 11:09:15 1998
+++ interfaces/perl5/Makefile.PL.in Thu Oct 15 11:57:17 1998
@@ -0,0 +1,44 @@
+#-------------------------------------------------------
+#
+# $Id: Makefile.PL,v 1.9 1998/09/27 19:12:21 mergl Exp $
+#
+# Copyright (c) 1997, 1998 Edmund Mergl
+#
+#-------------------------------------------------------
+
+use ExtUtils::MakeMaker;
+use Config;
+use strict;
+
+my %opts;
+
+if (! $ENV{POSTGRES_HOME}) {
+
+ my $cwd = `pwd`;
+ chop $cwd;
+
+ %opts = (
+ NAME => 'Pg',
+ VERSION_FROM => 'Pg.pm',
+ INC => "-I$cwd/../libpq -I$cwd/../../include",
+ OBJECT => "Pg\$(OBJ_EXT)",
+ LIBS => ["-L@prefix@/lib -L$cwd/../libpq -lpq"],
+ );
+
+} else {
+
+ %opts = (
+ NAME => 'Pg',
+ VERSION_FROM => 'Pg.pm',
+ INC => "-I$ENV{POSTGRES_HOME}/include",
+ OBJECT => "Pg\$(OBJ_EXT)",
+ LIBS => ["-L$ENV{POSTGRES_HOME}/lib -lpq"],
+ );
+}
+
+
+WriteMakefile(%opts);
+
+exit(0);
+
+# end of Makefile.PL
===========================================================================
--- interfaces/Makefile.orig Wed Oct 7 01:00:23 1998
+++ interfaces/Makefile Tue Oct 13 16:29:16 1998
@@ -15,13 +15,11 @@
include $(SRCDIR)/Makefile.global
-perl-makefile-dep :=
-ifeq ($(USE_PERL), true)
- perl-makefile-dep := perl5/Makefile
-endif
+PERL_CLEAN := DO_NOTHING
+install: PERL_CLEAN := clean
-.DEFAULT all install clean dep depend distclean: $(perl-makefile-dep)
+.DEFAULT all install clean dep depend distclean:
$(MAKE) -C libpq $@
$(MAKE) -C ecpg $@
ifeq ($(HAVE_Cplusplus), true)
@@ -33,6 +31,8 @@
$(MAKE) -C libpgtcl $@
endif
ifeq ($(USE_PERL), true)
+ -$(MAKE) -C perl5 $(PERL_CLEAN)
+ $(MAKE) perl5/Makefile
$(MAKE) -C perl5 $@
endif
ifeq ($(USE_ODBC), true)
===========================================================================
--- configure.in.orig Thu Oct 15 01:00:20 1998
+++ configure.in Thu Oct 15 11:54:09 1998
@@ -266,17 +266,6 @@
[ USE_PERL=false; AC_MSG_RESULT(disabled) ]
)
-#dnl Verify that postgres is already installed
-#dnl per instructions for perl interface installation
-if test "$USE_PERL" = "true"
-then
- if test "$WHOAMI" != "root"
- then AC_MSG_WARN(perl support disabled; must be root to install)
- USE_PERL=
- fi
-fi
-export USE_PERL
-
dnl We include odbc support unless we disable it with --with-odbc=false
AC_MSG_CHECKING(setting USE_ODBC)
AC_ARG_WITH(
@@ -917,6 +906,7 @@
interfaces/libpgtcl/Makefile
interfaces/odbc/GNUmakefile
interfaces/odbc/Makefile.global
+ interfaces/perl5/Makefile.PL
pl/plpgsql/src/Makefile
pl/plpgsql/src/mklang.sql
pl/tcl/mkMakefile.tcldefs.sh
> Edmund is thinking of a different situation. The perl5 interface is > also a "Perl module", which means that it is supposed to build and > install under very rigid rules --- this is supposed to work: > perl Makefile.PL > make > make test > make install > > Ok, I see now. So, we need the following: > > - a Makefile.PL that works out of the box for the above sequence, > given that POSTGRES_HOME is set properly. > > - a Makefile.PL that works with the Postgres installation and gets the > right shared library, so if we run `make test' later (or use the > interface in any way) it works immediately upon Postgres > installation. > > A solution: > > - a default Makefile.PL that works > > - a Makefile.PL replaced from Makefile.PL.in that still works with the > above, but satisfies the second criterion. > > The patches below do this and I think satisfy all considerations > (you'll let me know if they don't, right? :) > > - Makefile.PL has an explanation and if POSTGRES_HOME is not set will > print a useful message. > > - Makefile.PL.in replaces that message with the right thing for > finding the installed shared library based on configure. > > - Makefile: same as before; do the clean before installing to pick up > the right shared library. Note that no clean is done for any other > targets. > > - configure.in: output Makefile.PL along with the rest. Note also, > that in the current version $WHOAMI is never set so the perl test > always fails. Perhaps this should be fixed by setting the variable > correctly, but in any case the comments no longer agree with this > stuff anyway. > > Cheers, > Brook This patch does not apply properly. Please resubmit. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Brook Milligan wrote: > > Edmund is thinking of a different situation. The perl5 interface is > also a "Perl module", which means that it is supposed to build and > install under very rigid rules --- this is supposed to work: > perl Makefile.PL > make > make test > make install > > Ok, I see now. So, we need the following: > > - a Makefile.PL that works out of the box for the above sequence, > given that POSTGRES_HOME is set properly. > > - a Makefile.PL that works with the Postgres installation and gets the > right shared library, so if we run `make test' later (or use the > interface in any way) it works immediately upon Postgres > installation. > let's forget about the make test. In order to get the right libpq.so it should be sufficient to change the Makefile in the interfaces directory in a way, that 'make' and 'make install' for perl5 is called after 'make install' in libpq. Of course I would have to adapt Makefile.PL in order to use pgsql/lib instead of pgsql/src/interfaces/libpq as linkpath for libpq.so. But: for 'make install' in the perl directory, you need to be root, because the perl installation usually is owned by root. How do you want to solve this problem ? Those people without root access can say 'perl Makefile.PL PREFIX=/my/perl_directory' to install the module into a private directory. Again this is not possible with a hard coded 'perl Makefile'. Edmund -- Edmund Mergl mailto:E.Mergl@bawue.de Im Haldenhau 9 http://www.bawue.de/~mergl 70565 Stuttgart fon: +49 711 747503 Germany
> Ok, I see now. So, we need the following: > > - a Makefile.PL that works out of the box for the above sequence, > given that POSTGRES_HOME is set properly. > > - a Makefile.PL that works with the Postgres installation and gets the > right shared library, so if we run `make test' later (or use the > interface in any way) it works immediately upon Postgres > installation. let's forget about the make test. In order to get the right libpq.so it should be sufficient to change the Makefile in the interfaces directory in a way, that 'make' and 'make install' for perl5 is called after 'make install' in libpq. Of course I would have to adapt Makefile.PL in order to use pgsql/lib instead of pgsql/src/interfaces/libpq as linkpath for libpq.so. I don't think we need to give up on make test. Either the installer already has postgresql installed and running (in which case the standard perl procedure with POSTGRES_HOME set will work) or he/she doesn't and is doing this as part of the main postgresql installation. In that case we just repeat the build after libpq is installed; no problem. But: for 'make install' in the perl directory, you need to be root, because the perl installation usually is owned by root. How do you want to solve this problem ? Those people without root access can say 'perl Makefile.PL PREFIX=/my/perl_directory' to install the module into a private directory. Again this is not possible with a hard coded 'perl Makefile'. This is a complication. Perhaps to be solved secondarily. For my information so I can think about solutions, in your command what exactly is PREFIX pointing to? Directly to the root of the perl library tree? Would a solution be to enhance the --with-perl option to point to the directory of interest unless configure is run by root? In that case the interfaces/Makefile could include the prefix argument if necessary and things would just work. If one does the perl stuff standalone, they can always issue the command with a prefix themselves. Let's get the rest of this done right first, though and worry about this root/nonroot install problem next. I goofed my earlier patches, so I'll resubmit them and go from there. Cheers, Brook
This patch does not apply properly. Please resubmit.
Sorry. Here is a set that works against my copy of the BETA2
tarball. Hope that works now.
Cheers,
Brook
===========================================================================
--- interfaces/perl5/Makefile.PL.orig Mon Sep 28 01:00:21 1998
+++ interfaces/perl5/Makefile.PL Thu Oct 15 12:55:19 1998
@@ -10,29 +10,25 @@
use Config;
use strict;
-# because the perl5 interface is always contained in the source tree,
-# we can be sure about the location of the include files and libs.
-# For development and testing we still test for POSTGRES_HOME.
-#
-#print "\nConfiguring Pg\n";
-#print "Remember to actually read the README file !\n";
-#die "\nYou didn't read the README file !\n" unless ($] >= 5.002);
-#
-#if (! $ENV{POSTGRES_HOME}) {
-# warn "\$POSTGRES_HOME not defined. Searching for PostgreSQL...\n";
-# foreach(qw(../../../ /usr/local/pgsql /usr/pgsql /home/pgsql /opt/pgsql /usr/local/postgres /usr/postgres
/home/postgres/opt/postgres)) {
-# if (-d "$_/lib") {
-# $ENV{POSTGRES_HOME} = $_;
-# last;
-# }
-# }
-#}
-#
-#if (-d "$ENV{POSTGRES_HOME}/lib") {
-# print "Found PostgreSQL in $ENV{POSTGRES_HOME}\n";
-#} else {
-# die "Unable to determine PostgreSQL\n";
-#}
+# This Makefile.PL is intended for standalone use when PostgreSQL is
+# already installed. In that case, install the perl module as follows:
+#
+# setenv POSTGRES_HOME /path/to/root/of/installed/postgres
+# perl Makefile.PL
+# make
+# make test
+# make install
+
+# During normal installation of PostgreSQL, this file will be replaced
+# by one derived from Makefile.PL.in so that the installed shared
+# library libpq.so will be found during installation of this module.
+# As a result, the POSTGRES_HOME environment variable need not be set
+# during PostgreSQL installation. Note that ../Makefile takes care of
+# the `perl Makefile.PL' command. Note also that it is still possible
+# to follow the standalone installation procedure, even after
+# configuring and installing PostgreSQL, because the `else'
+# conditional branch below is identical in both Makefile.PL and
+# Makefile.PL.in.
my %opts;
@@ -41,14 +37,17 @@
my $cwd = `pwd`;
chop $cwd;
- %opts = (
- NAME => 'Pg',
- VERSION_FROM => 'Pg.pm',
- INC => "-I$cwd/../libpq -I$cwd/../../include",
- OBJECT => "Pg\$(OBJ_EXT)",
- LIBS => ["-L$cwd/../libpq -lpq"],
- );
+ print "To install the perl interface for PostgreSQL do the following:\n";
+ print " - install PostgreSQL\n";
+ print " - set the POSTGRES_HOME environment variable appropriately\n";
+ print " - in this directory ($cwd):\n";
+ print " perl Makefile.PL\n";
+ print " make\n";
+ print " make test [ with a postmaster running ]\n";
+ print " make install\n";
+ exit(1);
+
} else {
%opts = (
===========================================================================
--- interfaces/perl5/Makefile.PL.in.orig Thu Oct 15 11:09:15 1998
+++ interfaces/perl5/Makefile.PL.in Thu Oct 15 11:57:17 1998
@@ -0,0 +1,44 @@
+#-------------------------------------------------------
+#
+# $Id: Makefile.PL,v 1.9 1998/09/27 19:12:21 mergl Exp $
+#
+# Copyright (c) 1997, 1998 Edmund Mergl
+#
+#-------------------------------------------------------
+
+use ExtUtils::MakeMaker;
+use Config;
+use strict;
+
+my %opts;
+
+if (! $ENV{POSTGRES_HOME}) {
+
+ my $cwd = `pwd`;
+ chop $cwd;
+
+ %opts = (
+ NAME => 'Pg',
+ VERSION_FROM => 'Pg.pm',
+ INC => "-I$cwd/../libpq -I$cwd/../../include",
+ OBJECT => "Pg\$(OBJ_EXT)",
+ LIBS => ["-L@prefix@/lib -L$cwd/../libpq -lpq"],
+ );
+
+} else {
+
+ %opts = (
+ NAME => 'Pg',
+ VERSION_FROM => 'Pg.pm',
+ INC => "-I$ENV{POSTGRES_HOME}/include",
+ OBJECT => "Pg\$(OBJ_EXT)",
+ LIBS => ["-L$ENV{POSTGRES_HOME}/lib -lpq"],
+ );
+}
+
+
+WriteMakefile(%opts);
+
+exit(0);
+
+# end of Makefile.PL
===========================================================================
--- interfaces/Makefile.orig Wed Oct 7 01:00:23 1998
+++ interfaces/Makefile Tue Oct 13 16:29:16 1998
@@ -15,13 +15,11 @@
include $(SRCDIR)/Makefile.global
-perl-makefile-dep :=
-ifeq ($(USE_PERL), true)
- perl-makefile-dep := perl5/Makefile
-endif
+PERL_CLEAN := DO_NOTHING
+install: PERL_CLEAN := clean
-.DEFAULT all install clean dep depend distclean: $(perl-makefile-dep)
+.DEFAULT all install clean dep depend distclean:
$(MAKE) -C libpq $@
$(MAKE) -C ecpg $@
ifeq ($(HAVE_Cplusplus), true)
@@ -33,6 +31,8 @@
$(MAKE) -C libpgtcl $@
endif
ifeq ($(USE_PERL), true)
+ -$(MAKE) -C perl5 $(PERL_CLEAN)
+ $(MAKE) perl5/Makefile
$(MAKE) -C perl5 $@
endif
ifeq ($(USE_ODBC), true)
===========================================================================
--- configure.in.orig Thu Oct 15 01:00:20 1998
+++ configure.in Thu Oct 15 11:54:09 1998
@@ -266,17 +266,6 @@
[ USE_PERL=false; AC_MSG_RESULT(disabled) ]
)
-#dnl Verify that postgres is already installed
-#dnl per instructions for perl interface installation
-if test "$USE_PERL" = "true"
-then
- if test "$WHOAMI" != "root"
- then AC_MSG_WARN(perl support disabled; must be root to install)
- USE_PERL=
- fi
-fi
-export USE_PERL
-
dnl We include odbc support unless we disable it with --with-odbc=false
AC_MSG_CHECKING(setting USE_ODBC)
AC_ARG_WITH(
@@ -917,6 +906,7 @@
interfaces/libpgtcl/Makefile
interfaces/odbc/GNUmakefile
interfaces/odbc/Makefile.global
+ interfaces/perl5/Makefile.PL
pl/plpgsql/src/Makefile
pl/plpgsql/src/mklang.sql
pl/tcl/mkMakefile.tcldefs.sh
Applied.
> This patch does not apply properly. Please resubmit.
>
> Sorry. Here is a set that works against my copy of the BETA2
> tarball. Hope that works now.
>
> Cheers,
> Brook
>
> ===========================================================================
> --- interfaces/perl5/Makefile.PL.orig Mon Sep 28 01:00:21 1998
> +++ interfaces/perl5/Makefile.PL Thu Oct 15 12:55:19 1998
> @@ -10,29 +10,25 @@
> use Config;
> use strict;
>
> -# because the perl5 interface is always contained in the source tree,
> -# we can be sure about the location of the include files and libs.
> -# For development and testing we still test for POSTGRES_HOME.
> -#
> -#print "\nConfiguring Pg\n";
> -#print "Remember to actually read the README file !\n";
> -#die "\nYou didn't read the README file !\n" unless ($] >= 5.002);
> -#
> -#if (! $ENV{POSTGRES_HOME}) {
> -# warn "\$POSTGRES_HOME not defined. Searching for PostgreSQL...\n";
> -# foreach(qw(../../../ /usr/local/pgsql /usr/pgsql /home/pgsql /opt/pgsql /usr/local/postgres /usr/postgres
/home/postgres/opt/postgres)) {
> -# if (-d "$_/lib") {
> -# $ENV{POSTGRES_HOME} = $_;
> -# last;
> -# }
> -# }
> -#}
> -#
> -#if (-d "$ENV{POSTGRES_HOME}/lib") {
> -# print "Found PostgreSQL in $ENV{POSTGRES_HOME}\n";
> -#} else {
> -# die "Unable to determine PostgreSQL\n";
> -#}
> +# This Makefile.PL is intended for standalone use when PostgreSQL is
> +# already installed. In that case, install the perl module as follows:
> +#
> +# setenv POSTGRES_HOME /path/to/root/of/installed/postgres
> +# perl Makefile.PL
> +# make
> +# make test
> +# make install
> +
> +# During normal installation of PostgreSQL, this file will be replaced
> +# by one derived from Makefile.PL.in so that the installed shared
> +# library libpq.so will be found during installation of this module.
> +# As a result, the POSTGRES_HOME environment variable need not be set
> +# during PostgreSQL installation. Note that ../Makefile takes care of
> +# the `perl Makefile.PL' command. Note also that it is still possible
> +# to follow the standalone installation procedure, even after
> +# configuring and installing PostgreSQL, because the `else'
> +# conditional branch below is identical in both Makefile.PL and
> +# Makefile.PL.in.
>
> my %opts;
>
> @@ -41,14 +37,17 @@
> my $cwd = `pwd`;
> chop $cwd;
>
> - %opts = (
> - NAME => 'Pg',
> - VERSION_FROM => 'Pg.pm',
> - INC => "-I$cwd/../libpq -I$cwd/../../include",
> - OBJECT => "Pg\$(OBJ_EXT)",
> - LIBS => ["-L$cwd/../libpq -lpq"],
> - );
> + print "To install the perl interface for PostgreSQL do the following:\n";
> + print " - install PostgreSQL\n";
> + print " - set the POSTGRES_HOME environment variable appropriately\n";
> + print " - in this directory ($cwd):\n";
> + print " perl Makefile.PL\n";
> + print " make\n";
> + print " make test [ with a postmaster running ]\n";
> + print " make install\n";
>
> + exit(1);
> +
> } else {
>
> %opts = (
> ===========================================================================
> --- interfaces/perl5/Makefile.PL.in.orig Thu Oct 15 11:09:15 1998
> +++ interfaces/perl5/Makefile.PL.in Thu Oct 15 11:57:17 1998
> @@ -0,0 +1,44 @@
> +#-------------------------------------------------------
> +#
> +# $Id: Makefile.PL,v 1.9 1998/09/27 19:12:21 mergl Exp $
> +#
> +# Copyright (c) 1997, 1998 Edmund Mergl
> +#
> +#-------------------------------------------------------
> +
> +use ExtUtils::MakeMaker;
> +use Config;
> +use strict;
> +
> +my %opts;
> +
> +if (! $ENV{POSTGRES_HOME}) {
> +
> + my $cwd = `pwd`;
> + chop $cwd;
> +
> + %opts = (
> + NAME => 'Pg',
> + VERSION_FROM => 'Pg.pm',
> + INC => "-I$cwd/../libpq -I$cwd/../../include",
> + OBJECT => "Pg\$(OBJ_EXT)",
> + LIBS => ["-L@prefix@/lib -L$cwd/../libpq -lpq"],
> + );
> +
> +} else {
> +
> + %opts = (
> + NAME => 'Pg',
> + VERSION_FROM => 'Pg.pm',
> + INC => "-I$ENV{POSTGRES_HOME}/include",
> + OBJECT => "Pg\$(OBJ_EXT)",
> + LIBS => ["-L$ENV{POSTGRES_HOME}/lib -lpq"],
> + );
> +}
> +
> +
> +WriteMakefile(%opts);
> +
> +exit(0);
> +
> +# end of Makefile.PL
> ===========================================================================
> --- interfaces/Makefile.orig Wed Oct 7 01:00:23 1998
> +++ interfaces/Makefile Tue Oct 13 16:29:16 1998
> @@ -15,13 +15,11 @@
> include $(SRCDIR)/Makefile.global
>
>
> -perl-makefile-dep :=
> -ifeq ($(USE_PERL), true)
> - perl-makefile-dep := perl5/Makefile
> -endif
> +PERL_CLEAN := DO_NOTHING
> +install: PERL_CLEAN := clean
>
>
> -.DEFAULT all install clean dep depend distclean: $(perl-makefile-dep)
> +.DEFAULT all install clean dep depend distclean:
> $(MAKE) -C libpq $@
> $(MAKE) -C ecpg $@
> ifeq ($(HAVE_Cplusplus), true)
> @@ -33,6 +31,8 @@
> $(MAKE) -C libpgtcl $@
> endif
> ifeq ($(USE_PERL), true)
> + -$(MAKE) -C perl5 $(PERL_CLEAN)
> + $(MAKE) perl5/Makefile
> $(MAKE) -C perl5 $@
> endif
> ifeq ($(USE_ODBC), true)
> ===========================================================================
> --- configure.in.orig Thu Oct 15 01:00:20 1998
> +++ configure.in Thu Oct 15 11:54:09 1998
> @@ -266,17 +266,6 @@
> [ USE_PERL=false; AC_MSG_RESULT(disabled) ]
> )
>
> -#dnl Verify that postgres is already installed
> -#dnl per instructions for perl interface installation
> -if test "$USE_PERL" = "true"
> -then
> - if test "$WHOAMI" != "root"
> - then AC_MSG_WARN(perl support disabled; must be root to install)
> - USE_PERL=
> - fi
> -fi
> -export USE_PERL
> -
> dnl We include odbc support unless we disable it with --with-odbc=false
> AC_MSG_CHECKING(setting USE_ODBC)
> AC_ARG_WITH(
> @@ -917,6 +906,7 @@
> interfaces/libpgtcl/Makefile
> interfaces/odbc/GNUmakefile
> interfaces/odbc/Makefile.global
> + interfaces/perl5/Makefile.PL
> pl/plpgsql/src/Makefile
> pl/plpgsql/src/mklang.sql
> pl/tcl/mkMakefile.tcldefs.sh
>
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Brook Milligan wrote: > > > Ok, I see now. So, we need the following: > > > > - a Makefile.PL that works out of the box for the above sequence, > > given that POSTGRES_HOME is set properly. > > > > - a Makefile.PL that works with the Postgres installation and gets the > > right shared library, so if we run `make test' later (or use the > > interface in any way) it works immediately upon Postgres > > installation. > > let's forget about the make test. In order to get the right > libpq.so it should be sufficient to change the Makefile in the > interfaces directory in a way, that 'make' and 'make install' > for perl5 is called after 'make install' in libpq. Of course > I would have to adapt Makefile.PL in order to use pgsql/lib > instead of pgsql/src/interfaces/libpq as linkpath for libpq.so. > > I don't think we need to give up on make test. Either the installer > already has postgresql installed and running (in which case the > standard perl procedure with POSTGRES_HOME set will work) or he/she > doesn't and is doing this as part of the main postgresql > installation. In that case we just repeat the build after libpq is > installed; no problem. > > But: for 'make install' in the perl directory, you need to be > root, because the perl installation usually is owned by root. > How do you want to solve this problem ? Those people without > root access can say 'perl Makefile.PL PREFIX=/my/perl_directory' > to install the module into a private directory. Again this > is not possible with a hard coded 'perl Makefile'. > > This is a complication. Perhaps to be solved secondarily. For my > information so I can think about solutions, in your command what > exactly is PREFIX pointing to? Directly to the root of the perl > library tree? > > Would a solution be to enhance the --with-perl option to point to the > directory of interest unless configure is run by root? In that case > the interfaces/Makefile could include the prefix argument if > necessary and things would just work. If one does the perl stuff > standalone, they can always issue the command with a prefix > themselves. > > Let's get the rest of this done right first, though and worry about > this root/nonroot install problem next. I goofed my earlier patches, > so I'll resubmit them and go from there. > > Cheers, > Brook the standard path for installing perl modules is .../lib/perl5/site_perl/... Only in case someone has no root access and no possibility to make a private perl installation, he will use the PREFIX option. The disadvantage of installing a module in a private directory is, in every perl script using this module the user will have to add the searchpath, so that perl is able to find the module at this non-standard place. Obviously this is only a work-around and should not be used unless the user has no root access and the user is forced to use the perl installation of the sys-admin. I guess in 95% the user/sys-admin will have to install the perl-module manually, which means - cd-ing into interfaces/perl5 - make install What's the big difference to: - cd-ing into interfaces/perl5 - perl Makefile.PL - make - make install In other words, I still prefer the solution not to build the perl module together with postgresql. I think it is sufficient to mention the perl module and the commands needed in order to install it in the INSTALL file and that's it. Edmund -- Edmund Mergl mailto:E.Mergl@bawue.de Im Haldenhau 9 http://www.bawue.de/~mergl 70565 Stuttgart fon: +49 711 747503 Germany
I have thought some more about the Perl-module-install problem,
and concluded that we still don't have it quite right. But I think
that I know how to do it right.
There are two problems remaining in Brook's latest patch:
1. Allowing Makefile.PL to be overwritten by configure from
Makefile.PL.in is a no-no. A cardinal rule of software source
distributions is that the build procedure must not modify any of the
files that are part of the distributed fileset. To do otherwise
creates a trap for developers (who might accidentally check in a
locally-customized copy instead of a pristine original), and a trap for
installers too (who cannot get back to the original fileset by doing
"make clean").
(I see that Bruce's actual installation of Brook's patch removed
Makefile.PL from the fileset. That avoids the above traps, but it
breaks the original goal of keeping the perl5 subdirectory a valid
stand-alone-installable Perl module.)
2. As it stands, when building in the Postgres source tree the Perl
module's search paths for include and lib files will be /usr/local/pgsql
(or local equivalent) *first*, the source tree *second*. This is no
good if you are installing a new Postgres version on a machine that
currently has an older one installed. The build phase will compile
and link the Perl module against the installed version in
/usr/local/pgsql, not against the new version in the surrounding source
tree. Sure, it'll get rebuilt correctly during the install pass, but
this approach offers no security that you actually have a working tree
until you do the install. If it's gonna fail, you'd like to know sooner
than that...
So, what we really want is a two-phase Perl module build/install
process: during the build phase, compile and link against the files
in the surrounding tree, ignoring /usr/local/pgsql entirely. In
the install phase (and not before then!), blow away that version and
rebuild using the already-installed include files and libpq library
file that now reside in /usr/local/pgsql. This ensures that the
completed Perl module will have the right path to the libpq library
(if the platform demands one).
Fortunately, it's easy to do this in a way that's compatible with also
supporting stand-alone installation of the Perl module. We make the
Perl module's Makefile.PL use relative paths (and *only* relative paths)
if POSTGRES_HOME is not defined, and we make it use POSTGRES_HOME
(*only*) if that environment variable is set. Then we tweak the
src/interfaces Makefile so that during "make install", we do "make
clean" and then re-execute Makefile.PL *with POSTGRES_HOME set*.
So during the install phase, the Perl module is rebuilt the same way
it would be if being installed standalone.
This is actually a lot simpler than what we had before.
A free side benefit is that our regular builds will test the
standalone-install code path, so we'll know if it breaks.
I'll test and check in the necessary changes this evening, unless
I hear loud protests...
regards, tom lane
I envision 2 general classes of postgresql installers: 1) root, and 2) nonroot users wishing to try/use postgresql. In the case of root sysadmins, everything (including perl) should install out of the box. It does so now without affecting the standalone perl interface installation. In the case of nonroot installers, there are two subcases: 2a) perl is installed in system directories with only root access, and 2b) perl was installed in some other place by the postgresql installer. In case 2b, again there is no problem. The install (with a suitable --prefix=... argument to configure) should proceed unimpeded. In case 2a, postgresql is installable under control of the --prefix=... argument, but there will be a conflict when perl is installed do to lack of access to the perl filesystem for the perl interface shared library. In this case, the installer can install postgresql WITHOUT the --with-perl option to configure. Later, someone with root permission can do the cd interfaces/perl5perl Makefile.PLmakemake testmake install sequence. I don't see any situations that lose here. Am I missing something? In conclusion, I see our current perl interface handling as addressing all the relevant conditions (thanks to Tom Lane for finishing it up!). Cheers, Brook