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

On 1/9/13 10:30 AM, Christian Ullrich wrote:
> * Christoph Berg wrote:
>
>> Re: Tom Lane 2013-01-09 <9802(dot)1357702675(at)sss(dot)pgh(dot)pa(dot)us>
>
>>> 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?)
>>
>> Because the .so symlink is only needed at build time. At runtime, you
>> need the .so.5.14 file. Hence .so.* -> $pkg, .h .a .so -> $pkg-dev.
>
> That was Tom's point, I believe -- Debian does not do it that way.
>
> - perl-base has /usr/lib/libperl.so.5.etc
> - perl has the headers and a dependency on perl-base
> - libperl-dev has the symlink /usr/lib/libperl.so > libperl.so.5.etc
>
> So by installing "perl", you get enough to satisfy configure, but there
> is still no usable -lperl.

The reason it's like that is that the header files are usable for
building Perl extensions, but that doesn't need the library. And the
expectation is that if you want to build against libfoo, you install
libfoo-dev. The fact that some other package also gives you half of
what you need is a coincidence.

The blame, if you want to assign any, is with configure, because it
assumes that the header files and the library are an atomic unit and
checks for the former and assumes the latter must be there as well.