Skip site navigation (1) Skip section navigation (2)

Re: PL/perl should fail on configure, not make

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tim Bunce <Tim(dot)Bunce(at)pobox(dot)com>
Subject: Re: PL/perl should fail on configure, not make
Date: 2013-01-09 03:37:55
Message-ID: 9802.1357702675@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> The way it is now (9.2.2):
> 1. set up a new system
> 2. forget to install libperl-dev
> 3. ./configure --with-perl
> 4. get no failures or warnings
> 5. make
> 6. make errors out on plperl.so

> The way it should work:

> - configure should error out, as it does with python.

I poked at this a bit more, and AFAICS your real beef is with Debian's
whacked-out packaging decisions for Perl.

Item: it's impossible to reproduce this failure on Red Hat-based
distros.  perl-devel is required by perl-ExtUtils-MakeMaker, without
which we'll definitely fail at configure time.  I doubt it's possible
in a hand-rolled install from source, either, because all that stuff
is part of the core perl tarball.

Item: there is *not* any test for libpython.so, as such, in our
configure script.  There is a test for Python.h, which is sufficient on
Red Hat systems as well as on Debian, because python-devel
(resp. python-dev) carries both the header files and the .so links.

Item: there is not a test for perl.h, as such, in configure.  There
probably should be, just because we have comparable tests for tcl.h
and Python.h.  However, adding one won't fix your problem on
Debian-based distros, because for some wacko reason they put the
headers and the shlib .so symlink in different packages, cf
http://packages.debian.org/squeeze/amd64/perl/filelist
http://packages.debian.org/squeeze/amd64/libperl-dev/filelist
I am unfamiliar with a good reason for doing that.  (I can certainly
see segregating the .a static library, or even not shipping it at
all, but what's it save to leave out the .so symlink?)

We could try adding an AC_TRY_LINK test using perl_embed_ldflags,
but given the weird stuff happening to redefine that value on Windows
in plperl/GNUmakefile I think there's a serious risk of breaking Cygwin
builds.  Since I lack access to either Cygwin or a platform on which
there's a problem today, I'm not going to be the one to mess with it.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Hari BabuDate: 2013-01-09 04:02:58
Subject: Re: Review of "pg_basebackup and pg_receivexlog to use non-blocking socket communication", was: Re: Re: [BUGS] BUG #7534: walreceiver takes long time to detect n/w breakdown
Previous:From: Josh KupershmidtDate: 2013-01-09 02:55:07
Subject: Re: bad examples in pg_dump README

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group