[devel] Re: q: _perl_vendor_check_dso problems

[Alexey Tourbin]

On Mon, Sep 26, 2005 at 05:23:23PM +0400, Vladimir Lettiev wrote:
> Нет, безрезультатно.
> Похоже все указанные функции проглядываются в *.h файлах, которые 
> принадлежат пакету apache-mod_perl.

Эти функции *должны* быть в какой-то *.so библиотеке.  Если эта
библиотека публичная, то есть предназначена для непосредственной
линковки, то лучше всего с ней слинковаться.

> Это где-то в этом районе:
> /usr/lib/perl5/vendor_perl/i386-linux/auto/Apache/include/

Если же это библиотека типа loadable module, то есть не предназначена
для непосредственной линковки, то можно "подстроить" проверку.  Пример
из perl-Gtk2-GladeXML.spec:

EXTRA_BLIBS=`ls %perl_vendor_autolib/{Glib/Glib,Gtk2/Gtk2}.so`
%perl_vendor_build

При загрузке Glib.so и Gtk2.so используется RTLD_GLOBAL, это такой
хитрый/окольный ELF механизм для глобального импорта символов из
объекта, который загружается с помощью dlopen().

Поиск по символам показывает, что функции ap_table_do и др. находятся
в /usr/lib/apache/libhttpd.so:

apache  /usr/lib/apache/libhttpd.so     T       ap_table_do
apache-mod_perl /usr/sbin/httpd-perl    T       ap_table_do

Я вообще не знаю, как всё это работает, то есть как в процессе
динамической линковки подцепляется libhttpd.so.  Если есть уверенность,
что оно действительно работает, то проще всего модифицировать проверку:

EXTRA_BLIBS=`ls %_libdir/apache/libhttpd.so`
%perl_vendor_build

Но у libhttpd.so в свою очередь тоже есть undefined symbols:

$ ldd -r /usr/lib/apache/libhttpd.so 2>&1 |head
        libc.so.6 => /lib/i686/libc.so.6 (0x40074000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
undefined symbol: mm_core_delete        (/usr/lib/apache/libhttpd.so)
undefined symbol: dlerror       (/usr/lib/apache/libhttpd.so)
undefined symbol: MM_create     (/usr/lib/apache/libhttpd.so)
undefined symbol: deflate       (/usr/lib/apache/libhttpd.so)
undefined symbol: mm_maxsize    (/usr/lib/apache/libhttpd.so)
undefined symbol: mm_core_align2page    (/usr/lib/apache/libhttpd.so)
undefined symbol: MM_destroy    (/usr/lib/apache/libhttpd.so)
undefined symbol: mm_create     (/usr/lib/apache/libhttpd.so)
$

Всё это как-то криво и работает "на честном слове и на одном крыле".
Символы MM_create и др. есть и libmm:

libmm   /usr/lib/libmm.so.1.3.0 T       MM_create

Если добавить в EXTRA_BLIBS libmm, то проверка опять не проходит:

$ gcc ~/ldtest.c /usr/lib/apache/libhttpd.so /usr/lib/libmm.so
/usr/lib/apache/libhttpd.so: undefined reference to `dlerror'
/usr/lib/apache/libhttpd.so: undefined reference to `deflate'
/usr/lib/apache/libhttpd.so: undefined reference to `dlclose'
/usr/lib/apache/libhttpd.so: undefined reference to `crc32'
/usr/lib/apache/libhttpd.so: undefined reference to `dlopen'
/usr/lib/apache/libhttpd.so: undefined reference to `deflateInit2_'
/usr/lib/apache/libhttpd.so: undefined reference to `crypt'
/usr/lib/apache/libhttpd.so: undefined reference to `dlsym'
/usr/lib/apache/libhttpd.so: undefined reference to `deflateEnd'

Опыты показывают, что проверка в конечном счете будет работать так:

$ gcc ~/ldtest.c /usr/lib/apache/libhttpd.so -lmm -ldl -lcrypt -lz

То есть придётся написать 

EXTRA_BLIBS='/usr/lib/apache/libhttpd.so -lmm -ldl -lcrypt -lz'
%perl_vendor_build

Излишне говорить, что всё это сводит на нет смысл проверки.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20050926/09e6165f/attachment-0001.bin>