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