Re: Problems with Perl

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: "Kevin O'Gorman" <kogorman(at)pacbell(dot)net>, PGSQL Hackers List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Problems with Perl
Date: 2000-11-10 21:50:18
Message-ID: 21730.973893018@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> 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?

I suppose you could do it that way if you were using gcc, but AFAICS
from its man page, the vendor cc has no switch to build libraries of
any sort. Just .o and executable files...

A bigger problem is that if interfaces/perl5 builds itself to refer to
an installed libpq to begin with, there'll be no way to run its selftest
without installing libpq first.

> And then, do we want to risk tricking around with MakeMaker, or should we
> go for an HPUX specific fix?

The real issue here is that make install builds new files in the source
tree. Perhaps "make install" should do a "make clean" after rebuilding
and installing.

Bear in mind that if we ever start using libtool, we will have this
problem all over the tree, not just in interfaces/perl5. At least on
HPUX, libtool's standard behavior is to relink just before install.
I would imagine that the other platforms with rpath capability would
do the same thing. So a perl-only solution may be pointless.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Larry Rosenman 2000-11-10 21:54:13 Horology failure on UW711/cc...
Previous Message Peter Eisentraut 2000-11-10 21:28:24 Re: Problems with Perl