Re: [HACKERS] perl interface bug? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] perl interface bug?
Date
Msg-id 6828.908407524@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] perl interface bug?  (Brook Milligan <brook@trillium.NMSU.Edu>)
Responses Re: [HACKERS] perl interface bug?  (Brook Milligan <brook@trillium.NMSU.Edu>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: Egon Schmid
Date:
Subject: Problems
Next
From: Bruce Momjian
Date:
Subject: Re: [HACKERS] PostgreSQL v6.4 BETA2 ...