Josh Berkus <josh@agliodbs.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