Kevin O'Gorman writes:
> 2) Because _something_ was made for Perl, the 'make install'
> has to be root. Okay. But this is leaving some stuff behind
> that is owned by root. When I attempt a subsequent
> 'make clean; make' I get into permissions trouble, and have
> to delete these things manually.
Yes, this is definitely broken. I just read that old thread ("[HACKERS]
perl interface bug?", 14 October 1998), and it was already considered
questionable then.
To recap, the Pg.so thing needs to know where libpq lives. If you link
with libpq out of the source tree then Pg.so forever tries to find libpq
there. So you relink Pg.so during 'make install' when libpq is already
installed at it's final location.
If I'm not completely mistaken, this behaviour could really only happen on
HPUX. Also on other platforms you would normally have to point
LD_LIBRARY_PATH to $(libdir) in order to get anything at all working.
Theoretically we could fix this now by sneaking the $(rpath) make variable
in to MakeMaker somehow, perhaps via OTHERLDFLAGS. However, the flag in
this variable is supposed to be used by the compiler driver -- if Perl
decides to use 'ld' to link the module you lose.
More to the point, 'rpath' is currently undefined on HPUX because HPUX
uses 'ld' to link shared libraries, but the shared library link uses
$(rpath), so it would break. Perhaps to start with, is there a way to use
the compiler driver to link shared libraries on HPUX?
And then, do we want to risk tricking around with MakeMaker, or should we
go for an HPUX specific fix?
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/