Horton

Thread

  1. Re: [HACKERS] perl interface bug?

    Tom Lane <tgl@sss.pgh.pa.us> — 1998-10-14T21:14:47Z

    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

  2. Re: [HACKERS] perl interface bug?

    Brook Milligan <brook@trillium.nmsu.edu> — 1998-10-14T22:07:25Z

       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

  3. Re: [HACKERS] perl interface bug?

    Bruce Momjian <maillist@candle.pha.pa.us> — 1998-10-15T01:49:38Z

    > 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

  4. Re: [HACKERS] perl interface bug?

    Edmund Mergl <e.mergl@bawue.de> — 1998-10-15T07:58:16Z

    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

  5. Re: [HACKERS] perl interface bug?

    Brook Milligan <brook@trillium.nmsu.edu> — 1998-10-15T14:21:13Z

       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