Re: Problems with Perl
От | Peter Eisentraut |
---|---|
Тема | Re: Problems with Perl |
Дата | |
Msg-id | Pine.LNX.4.21.0011102200130.775-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Problems with Perl ("Kevin O'Gorman" <kogorman@pacbell.net>) |
Ответы |
Re: Problems with Perl
|
Список | pgsql-hackers |
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/
В списке pgsql-hackers по дате отправления: