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

Поиск
Список
Период
Сортировка
От Christian Ullrich
Тема Re: PL/perl should fail on configure, not make
Дата
Msg-id kck2do$6no$1@ger.gmane.org
обсуждение исходный текст
Ответ на Re: PL/perl should fail on configure, not make  (Christoph Berg <myon@debian.org>)
Ответы Re: PL/perl should fail on configure, not make  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: PL/perl should fail on configure, not make  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
* Christoph Berg wrote:

> Re: Tom Lane 2013-01-09 <9802.1357702675@sss.pgh.pa.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.

-- 
Christian








В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH 1/2] Provide a common malloc wrappers and palloc et al. emulation for frontend'ish environs
Следующее
От: Fujii Masao
Дата:
Сообщение: segmentation fault in pg_basebackup