Cristian Gafton <gafton@redhat.com> writes:
> On Tue, 29 Jun 1999, Thomas Lockhart wrote:
>> The problem is that, apparently,
>> perl Makefile.PL
>> generates paths which are *very* specific to the version of perl on
> That should not be the case. It depends on how the Postgres package
> Makefile.PL is written, but in general it should go into a general use
> perl5 directory, such as /usr/lib/perl5/site_perl, which is anything but
> perl version dependant. If it generates paths that are perl version
> dependent then the Makefile.PL is busted.
Au contraire. That may be true for pure-Perl packages, but packages
that involve compiled code (as our perl5 interface surely does) go
into strongly version-dependent directories. On my box, for example,
the install procedure wants to put stuff into both
/opt/perl5/lib/site_perl/PA-RISC1.1/auto/Pg/ and
/opt/perl5/lib/PA-RISC1.1/5.00404/
which means it is dependent on (a) where the Perl install tree is
(/opt/perl5 is standard on SysV-derived systems, but not elsewhere),
(b) the hardware architecture (PA-RISC1.1 here), and (c) the Perl
subversion (5.004_04 here).
The dependence on hardware architecture is obviously essential, since
the compiled code could not work anywhere else. You can quibble about
whether code compiled against 5.004_04 Perl headers would work on a
wider range of Perl versions, but the fundamental bottom line is that
Perl expects addon modules to be transported in source form and
compiled against the local installation. Violating that assumption
is a recipe for trouble.
regards, tom lane
