Thread
-
Re: [HACKERS] perl interface bug?
Tom Lane <tgl@sss.pgh.pa.us> — 1998-10-14T23:25:24Z
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
-
Re: [HACKERS] perl interface bug?
Brook Milligan <brook@trillium.nmsu.edu> — 1998-10-15T14:16:01Z
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